[Catalyst] From Development to Production.

Wed Mar 2 20:49:40 GMT 2016

We've solved these problems for our environement, but I was not willing to
go into that level of detail

Your suggestion validated how we're doing it,
so thank you for your feedback.

On Thu, Mar 03, 2016 at 07:31:08AM +1100, Kieren Diment wrote:
> As far as managing your perl/cpan version goes here's one low friction
> solution:
> 
> 1.  Make sure your dev box and production box are the same architecture.
> 2.  Use perlbrew or similar to install a perl to /opt/perl
> 3.  Copy the /opt/perl directory  between development and production
> (rsync, make a deb and dpkg -i or whatever).
> 4.  Make sure your PATH environment variables are set correctly.
> 
> On Thu, Mar 3, 2016 at 7:23 AM, 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.
> >
> > 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