and I don't want any "different versions of dependencies" bugs wasting my time.
=) https://www.youtube.com/watch?v=tHioEC9itTg ----- Original Message ----- From: "Trevor Leffler" <tleff...@uw.edu> To: "The elegant MVC web framework" <catalyst@lists.scsys.co.uk> Sent: Wednesday, March 02, 2016 8:40 PM Subject: Re: [Catalyst] From Development to Production. +1 for Carton for managing perl application dependencies. Also perlbrew or plenv for using your own perl / separating your app from the system perl. I agree whole-heartedly with James regarding being able to stabilize your app's environment and being able to consistently reproduce it. Whether I'm spinning up a new prod server or getting a new developer up and running, I want a [near] push-button method for getting the app running as quickly as possible, and I don't want any "different versions of dependencies" bugs wasting my time. --Trevor On 03/02/2016 12:23 PM, James Leu 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" <tleff...@uw.edu> >> To: "The elegant MVC web framework" <catalyst@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:catalystgr...@unitedgames.co.uk> >>> Sent: 3/2/2016 20:17 >>> To: The elegant MVC web framework <mailto:catalyst@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@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@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@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@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@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/