[Catalyst] From Development to Production.

[Bill Moseley]

On Wed, Mar 9, 2016 at 7:35 AM, Dermot <paikkos at gmail.com> wrote:

I want to caution you, in the nicest possible way. Writing software
> requires a number of skills and a lot of research and learning. You can't
> avoid the latter. What may seem like a lot of unnecessary aggravation
> (testing and version control) have come about because it's no fun fixing
> problems after the event.
>

Very true.

Andrew, there's an overwhelming amount of reading on this topic. If you
think there's *any* chance that your app will grow in usage and developers
over time then it's well worth planning ahead.  Automate *everything* from
the start.   It's critical to make deployments fast, repeatable, and dead
simple.   Probably should also include "scalable" there as a good buzzword.

Here's a few random links to get you thinking:

http://12factor.net/
https://zachholman.com/posts/deploying-software
https://guides.github.com/introduction/flow/ (we do a modified version of
this)

The bottom line is you want to be spending your energy on the application
functionality and not on deploying and running the application -- which
seems to consume time exponentially if not careful.


To be honest we have not really found a perfect way of managing Perl
dependencies.   I think the standard Perl module versioning system falls
apart when there's lots of developers, many "apps" involved, and a version
control system.  Our single app turned into many Catalyst apps that (with
the goal of)  have "thin" controllers and many models.  Those models were
originally separate Dist::Zilla Perl distributions in our local DarkPAN.
As those were updated with new version numbers the apps were also updated
to depended on those.   This breaks down when using Git and heavy use of
branches because versions are no longer linear -- instead small features
and fixes are merged individually.

We have swung quite far the other way now and moving toward separate repos
for each "app" and even copying the same module into multiple repos to
promote decoupling (and the cost of code duplication).   We are also using
Carton to lock down versions and bundle dependencies.

We have also put Perlbrew into Git with mixed results.    I'm not a big fan
of placing build artifacts into Git, but having the entire app in a single
repo does have benefits.

We would like to get to a CI pipeline that generates a Docker container and
use that for all non-dev deployments.  You never know when you will need to
deploy a million containers <https://www.hashicorp.com/c1m.html>...



-- 
Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/catalyst/attachments/20160319/88751957/attachment.htm>