[Catalyst] From Development to Production.

James Leu jleu at mindspring.com
Wed Mar 2 20:54:01 GMT 2016


Lasse

One thing to consider about your approach is that the XS backed modules
have compile code which links against system libs.  If you upgrade
your systems libs (for a libc security vunerability ;-) then you
need to rebuild all your XS backed modules.

So being able to reproduce the exact same versions of modules
over time would still be needed.

On Wed, Mar 02, 2016 at 09:41:41PM +0100, Lasse Makholm wrote:
> On Wed, Mar 2, 2016 at 9:23 PM, James Leu <jleu at mindspring.com> wrote:
> 
> > It all comes down to the apps 'environment`.
> >
> > Do you remember when you started developing your catalyst app you had to
> > install a bunch of perl modules?
> >
> > Those same modules (preferabbly the EXACT same versions as you installed
> > on your development machine) need to be installed on your
> > production machine.  Once you have the same 'environment'
> > between dev and prod, then yeah, you can just 'copy' your
> > app's source tree to prod, and it will "just work".
> >
> > The problem we run into is that CPAN is a moving target.
> > Install Catalyst today might result in different versions
> > of modules, then when you install catalyst to start you development.
> > Those differences in versions of modules can result in complete
> > failure of the app or small subtle changes in the way it runs, or even
> > worse, exposes a new exploitable bug in your app.
> >
> > So consistency of you apps 'environment' between dev, production,
> > and production a year from now, it one of the biggest challenges
> > to your approach.
> >
> > You can look into things like Carton, PAR, FatPacker which will
> > bundle up the perl environment for an App so you can
> > deploy it.
> >
> 
> FWIW, I looked into all of those for $work and ended up just using
> local::lib and cpanm to install dependencies into a directory tracked in a
> git repository. The repo has 3 branches; dev, staging and production
> corresponding to our environments. So to promote something, just merge from
> e.g. staging to production. Whenever we deploy a new version we just do a
> git pull in the CPAN repo on all boxes geting the new release. I'm quite
> happy with the setup. Adding new dependencies, tracking changes, etc, is
> super easy (assuming you know git). CHANGES files etc are nice, but the
> ability to to just run git diff after updating something to see exactly
> what changed is invaluable IMO. Additionally, cpanm's ability to install
> from e.g. git(hub) repos makes it super easy to install custom forks of
> CPAN modules.
> 
> /L
> 
> 
> > If you like to be 'ahead of the curve', start looking at using docker
> > or atomic for each of you web apps.
> >
> > Best of luck
> >
> > On Wed, Mar 02, 2016 at 07:04:53PM -0000, Andrew wrote:
> > > ---> Really looking to keep it simple stupid, to be fair.
> > >
> > > ---> Looks like a lot to learn atm, so am likely to just copy and paste
> > > folders for the time being.
> > >
> > > ---> I got a bit confused here:
> > >
> > > As a baby-step prior to doing builds and auto deployment, you can
> > > checkout your code from your production server(s).  While this is still
> > > a manual step, it's probably better than copying folders and files.
> > >
> > > ---> If you're not doing an auto deployment, and you're not copying
> > folders
> > > and files, how are you checking out your code from the production server?
> > >
> > > Grateful for all the insights,
> > >
> > > Yours,
> > > Andrew.
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Trevor Leffler" <tleffler at uw.edu>
> > > To: "The elegant MVC web framework" <catalyst at lists.scsys.co.uk>
> > > Sent: Wednesday, March 02, 2016 6:54 PM
> > > Subject: Re: [Catalyst] From Development to Production.
> > >
> > >
> > > Yes, that.  But to be a tad verbose about it...
> > >
> > > Use version control and branches (or whatever your VCS prefers).  Cut a
> > > new branch whenever you want to create a new "release" for production.
> > > This will let you switch from one branch to the next (upgrade) or back
> > > again if things blow up.
> > >
> > > As a baby-step prior to doing builds and auto deployment, you can
> > > checkout your code from your production server(s).  While this is still
> > > a manual step, it's probably better than copying folders and files.
> > >
> > > Once you're there, start looking into "builds."  Generally folks use
> > > some kind of Continuous Integration (CI) software that polls your VCS
> > > for recent commits and then "kicks off a build."  The simplest thing it
> > > might do is checkout the latest code revision and tar it up.  This
> > > tarfile is a "build artifact" ready for you to deploy (i.e. copy into
> > > production and untar).  Your work after this point is to figure out what
> > > else you'd like to happen during a build -- run tests? create
> > > documentation? do code inspections? -- and research how your build
> > > artifacts could be automatically deployed.
> > >
> > > I'll echo Toomas in that there's a lot to learn here and keep you busy
> > > depending on how far you want/can take it.
> > >
> > > Cheers,
> > > --Trevor
> > >
> > >
> > > On 03/02/2016 10:32 AM, Toomas Pelberg wrote:
> > > > Go learn about version control and deployment automation, you can
> > google
> > > > these keywords and will likely be busy for the next few weeks ;-) it's
> > a
> > > > pretty wide and interesting reading
> > > >
> > ------------------------------------------------------------------------
> > > > From: Andrew <mailto:catalystgroup at unitedgames.co.uk>
> > > > Sent: ‎3/‎2/‎2016 20:17
> > > > To: The elegant MVC web framework <mailto:catalyst at lists.scsys.co.uk>
> > > > Subject: [Catalyst] From Development to Production.
> > > >
> > > > So, I'm trying to learn Modern Perl workflows,
> > > > and I heard it's best to do all your development on a development
> > server,
> > > > rather than mess around with code live, on the production server.
> > > > So let's say I've coded my Catalyst app on a dev server, and it's in a
> > > > folder called MyApp....
> > > > Do I just copy the MyApp folder to the Production Server?
> > > > [Am likely to copy and paste the folder using Cyberduck].
> > > > I mean, assuming the production server is setup to run it, and so
> > forth...
> > > > Let's for example say, I'd already published Version 1.0 of my website
> > > > on the production server.
> > > > And it's running from a MyApp directory on the production server.
> > > > Then I code a version 2.0 on my development server, in a folder called
> > > > MyApp, and I want to publish that....
> > > > ...do I just again, copy MyApp from my development server, over to my
> > > > production server?
> > > > Obviously, new files would overwrite old ones.
> > > > What about if version 2.0 saw me delete some old unused stuff, do I
> > have
> > > > to make a note of what they were,
> > > > and go through the folder on the production server and delete them?
> > > > Or is there some graceful way to sync the development and production
> > > > versions of my code?
> > > > What are other people doing?
> > > > Grateful for any insights.
> > > > Yours,
> > > > Andrew.
> > > >
> > > >
> > > > _______________________________________________
> > > > List: Catalyst at lists.scsys.co.uk
> > > > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> > > > Searchable archive:
> > > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> > > > Dev site: http://dev.catalyst.perl.org/
> > > >
> > >
> > > _______________________________________________
> > > List: Catalyst at lists.scsys.co.uk
> > > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> > > Searchable archive:
> > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> > > Dev site: http://dev.catalyst.perl.org/
> > >
> > >
> > >
> > > _______________________________________________
> > > List: Catalyst at lists.scsys.co.uk
> > > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> > > Searchable archive:
> > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> > > Dev site: http://dev.catalyst.perl.org/
> >
> >
> > --
> > James R. Leu
> > jleu at mindspring.com
> >
> > _______________________________________________
> > List: Catalyst at lists.scsys.co.uk
> > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> > Searchable archive:
> > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> > Dev site: http://dev.catalyst.perl.org/
> >


-- 
James R. Leu
jleu at mindspring.com



More information about the Catalyst mailing list