<div dir="ltr"><div><div><div><div>As far as managing your perl/cpan version goes here's one low friction solution:<br><br></div>1. Make sure your dev box and production box are the same architecture.<br></div>2. Use perlbrew or similar to install a perl to /opt/perl<br></div>3. Copy the /opt/perl directory between development and production (rsync, make a deb and dpkg -i or whatever).<br></div>4. Make sure your PATH environment variables are set correctly.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 3, 2016 at 7:23 AM, James Leu <span dir="ltr"><<a href="mailto:jleu@mindspring.com" target="_blank">jleu@mindspring.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It all comes down to the apps 'environment`.<br>
<br>
Do you remember when you started developing your catalyst app you had to<br>
install a bunch of perl modules?<br>
<br>
Those same modules (preferabbly the EXACT same versions as you installed<br>
on your development machine) need to be installed on your<br>
production machine. Once you have the same 'environment'<br>
between dev and prod, then yeah, you can just 'copy' your<br>
app's source tree to prod, and it will "just work".<br>
<br>
The problem we run into is that CPAN is a moving target.<br>
Install Catalyst today might result in different versions<br>
of modules, then when you install catalyst to start you development.<br>
Those differences in versions of modules can result in complete<br>
failure of the app or small subtle changes in the way it runs, or even<br>
worse, exposes a new exploitable bug in your app.<br>
<br>
So consistency of you apps 'environment' between dev, production,<br>
and production a year from now, it one of the biggest challenges<br>
to your approach.<br>
<br>
You can look into things like Carton, PAR, FatPacker which will<br>
bundle up the perl environment for an App so you can<br>
deploy it.<br>
<br>
If you like to be 'ahead of the curve', start looking at using docker<br>
or atomic for each of you web apps.<br>
<br>
Best of luck<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Mar 02, 2016 at 07:04:53PM -0000, Andrew wrote:<br>
> ---> Really looking to keep it simple stupid, to be fair.<br>
><br>
> ---> Looks like a lot to learn atm, so am likely to just copy and paste<br>
> folders for the time being.<br>
><br>
> ---> I got a bit confused here:<br>
><br>
> As a baby-step prior to doing builds and auto deployment, you can<br>
> checkout your code from your production server(s). While this is still<br>
> a manual step, it's probably better than copying folders and files.<br>
><br>
> ---> If you're not doing an auto deployment, and you're not copying folders<br>
> and files, how are you checking out your code from the production server?<br>
><br>
> Grateful for all the insights,<br>
><br>
> Yours,<br>
> Andrew.<br>
><br>
><br>
><br>
> ----- Original Message -----<br>
> From: "Trevor Leffler" <<a href="mailto:tleffler@uw.edu">tleffler@uw.edu</a>><br>
> To: "The elegant MVC web framework" <<a href="mailto:catalyst@lists.scsys.co.uk">catalyst@lists.scsys.co.uk</a>><br>
> Sent: Wednesday, March 02, 2016 6:54 PM<br>
> Subject: Re: [Catalyst] From Development to Production.<br>
><br>
><br>
> Yes, that. But to be a tad verbose about it...<br>
><br>
> Use version control and branches (or whatever your VCS prefers). Cut a<br>
> new branch whenever you want to create a new "release" for production.<br>
> This will let you switch from one branch to the next (upgrade) or back<br>
> again if things blow up.<br>
><br>
> As a baby-step prior to doing builds and auto deployment, you can<br>
> checkout your code from your production server(s). While this is still<br>
> a manual step, it's probably better than copying folders and files.<br>
><br>
> Once you're there, start looking into "builds." Generally folks use<br>
> some kind of Continuous Integration (CI) software that polls your VCS<br>
> for recent commits and then "kicks off a build." The simplest thing it<br>
> might do is checkout the latest code revision and tar it up. This<br>
> tarfile is a "build artifact" ready for you to deploy (i.e. copy into<br>
> production and untar). Your work after this point is to figure out what<br>
> else you'd like to happen during a build -- run tests? create<br>
> documentation? do code inspections? -- and research how your build<br>
> artifacts could be automatically deployed.<br>
><br>
> I'll echo Toomas in that there's a lot to learn here and keep you busy<br>
> depending on how far you want/can take it.<br>
><br>
> Cheers,<br>
> --Trevor<br>
><br>
><br>
> On 03/02/2016 10:32 AM, Toomas Pelberg wrote:<br>
> > Go learn about version control and deployment automation, you can google<br>
> > these keywords and will likely be busy for the next few weeks ;-) it's a<br>
> > pretty wide and interesting reading<br>
> > ------------------------------------------------------------------------<br>
> > From: Andrew <mailto:<a href="mailto:catalystgroup@unitedgames.co.uk">catalystgroup@unitedgames.co.uk</a>><br>
> > Sent: 3/2/2016 20:17<br>
> > To: The elegant MVC web framework <mailto:<a href="mailto:catalyst@lists.scsys.co.uk">catalyst@lists.scsys.co.uk</a>><br>
> > Subject: [Catalyst] From Development to Production.<br>
> ><br>
> > So, I'm trying to learn Modern Perl workflows,<br>
> > and I heard it's best to do all your development on a development server,<br>
> > rather than mess around with code live, on the production server.<br>
> > So let's say I've coded my Catalyst app on a dev server, and it's in a<br>
> > folder called MyApp....<br>
> > Do I just copy the MyApp folder to the Production Server?<br>
> > [Am likely to copy and paste the folder using Cyberduck].<br>
> > I mean, assuming the production server is setup to run it, and so forth...<br>
> > Let's for example say, I'd already published Version 1.0 of my website<br>
> > on the production server.<br>
> > And it's running from a MyApp directory on the production server.<br>
> > Then I code a version 2.0 on my development server, in a folder called<br>
> > MyApp, and I want to publish that....<br>
> > ...do I just again, copy MyApp from my development server, over to my<br>
> > production server?<br>
> > Obviously, new files would overwrite old ones.<br>
> > What about if version 2.0 saw me delete some old unused stuff, do I have<br>
> > to make a note of what they were,<br>
> > and go through the folder on the production server and delete them?<br>
> > Or is there some graceful way to sync the development and production<br>
> > versions of my code?<br>
> > What are other people doing?<br>
> > Grateful for any insights.<br>
> > Yours,<br>
> > Andrew.<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > List: <a href="mailto:Catalyst@lists.scsys.co.uk">Catalyst@lists.scsys.co.uk</a><br>
> > Listinfo: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst" rel="noreferrer" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a><br>
> > Searchable archive:<br>
> <a href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/" rel="noreferrer" target="_blank">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a><br>
> > Dev site: <a href="http://dev.catalyst.perl.org/" rel="noreferrer" target="_blank">http://dev.catalyst.perl.org/</a><br>
> ><br>
><br>
> _______________________________________________<br>
> List: <a href="mailto:Catalyst@lists.scsys.co.uk">Catalyst@lists.scsys.co.uk</a><br>
> Listinfo: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst" rel="noreferrer" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a><br>
> Searchable archive: <a href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/" rel="noreferrer" target="_blank">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a><br>
> Dev site: <a href="http://dev.catalyst.perl.org/" rel="noreferrer" target="_blank">http://dev.catalyst.perl.org/</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> List: <a href="mailto:Catalyst@lists.scsys.co.uk">Catalyst@lists.scsys.co.uk</a><br>
> Listinfo: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst" rel="noreferrer" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a><br>
> Searchable archive: <a href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/" rel="noreferrer" target="_blank">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a><br>
> Dev site: <a href="http://dev.catalyst.perl.org/" rel="noreferrer" target="_blank">http://dev.catalyst.perl.org/</a><br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
James R. Leu<br>
<a href="mailto:jleu@mindspring.com">jleu@mindspring.com</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
List: <a href="mailto:Catalyst@lists.scsys.co.uk">Catalyst@lists.scsys.co.uk</a><br>
Listinfo: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst" rel="noreferrer" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a><br>
Searchable archive: <a href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/" rel="noreferrer" target="_blank">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a><br>
Dev site: <a href="http://dev.catalyst.perl.org/" rel="noreferrer" target="_blank">http://dev.catalyst.perl.org/</a><br>
</div></div></blockquote></div><br></div>