[Catalyst] From Development to Production.

Wed Mar 2 20:31:08 GMT 2016

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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/catalyst/attachments/20160303/87a212db/attachment.htm>