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 <j...@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" <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/ > > > > > > -- > > James R. Leu > > j...@mindspring.com > > > > _______________________________________________ > > 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/ > > -- James R. Leu j...@mindspring.com _______________________________________________ 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/