[Catalyst] From Development to Production.

Thu Mar 3 14:20:43 GMT 2016

Jorge,

Did you rebuild for each major release change?  Even that would
not be so bad. Rebuild, re-test and you're good for 2-3 year ;-)

Ofcourse this assumes the architecture of dev and prod are the same.
But realistically, does anyone use anything except x86_64?
I guess there might be a time when ARM64 becomes viable.  I suppose the
solution for this is to just maintain a seperate branch for each arch you
need to test/deploy on.

Thank you for enlightening me. Now that I've thought this though
a little more I may rethink some of my deployment senarios :-)

On Thu, Mar 03, 2016 at 09:57:47AM +0100, Jorge Gonzalez wrote:
> Of course, ALWAYS TEST your upgrades in your development or integration
> environment before doing it in production! :-)
> Jorge González Villalonga
> Consultor de Sistemas
> Red Hat Certified Engineer #140-183-666
> Móvil: (+34) 672 173 200
> 
> La información contenida en este mensaje y/o archivo(s) adjunto(s) es
> confidencial/privilegiada y está destinada a ser leída sólo por la(s)
> persona(s) a la(s) que va dirigida. Si usted lee este mensaje y no es el
> destinatario señalado, el empleado o el agente responsable de entregar el
> mensaje al destinatario, o ha recibido esta comunicación por error, le
> informamos que está totalmente prohibida, y puede ser ilegal, cualquier
> divulgación, distribución o reproducción de esta comunicación. Le rogamos
> que nos lo notifique inmediatamente y nos devuelva el mensaje original a la
> dirección arriba mencionada. Gracias.
> 
> El 03/03/16 a las 09:39, Toomas Pelberg escribió:
> >This is more or less true, but DO read the changelogs because it can and
> >will bite you.
> >------------------------------------------------------------------------
> >From: Jorge Gonzalez <mailto:jorge.gonzalez at daikon.es>
> >Sent: ‎3/‎3/‎2016 10:34
> >To: catalyst at lists.scsys.co.uk <mailto:catalyst at lists.scsys.co.uk>
> >Subject: Re: [Catalyst] From Development to Production.
> >
> >This is not exact.
> >
> >If you upgrade system libs (provided it's an upgrade for the same release
> >of your distribution), you should not need to recompile anything. Binary
> >API is guaranteed to remain compatible between upgrades of the same major
> >version of a library.
> >
> >In fact, I am doing it all the time in production: I keep the app install
> >untouched, but I regularly upgrade the underlying OS (i.e. Centos
> >5.x/6.x). Everything keeps working without problems.
> >
> >Regards
> >J.
> >Jorge González Villalonga
> >Consultor de Sistemas
> >Red Hat Certified Engineer #140-183-666
> >Móvil: (+34) 672 173 200
> >
> >La información contenida en este mensaje y/o archivo(s) adjunto(s) es
> >confidencial/privilegiada y está destinada a ser leída sólo por la(s)
> >persona(s) a la(s) que va dirigida. Si usted lee este mensaje y no es el
> >destinatario señalado, el empleado o el agente responsable de entregar el
> >mensaje al destinatario, o ha recibido esta comunicación por error, le
> >informamos que está totalmente prohibida, y puede ser ilegal, cualquier
> >divulgación, distribución o reproducción de esta comunicación. Le rogamos
> >que nos lo notifique inmediatamente y nos devuelva el mensaje original a
> >la dirección arriba mencionada. Gracias.
> >
> >El 02/03/16 a las 21:54, James Leu escribió:
> >>Lasse
> >>
> >>One thing to consider about your approach is that the XS backed modules
> >>have compile code which links against system libs.  If you upgrade
> >>your systems libs (for a libc security vunerability ;-) then you
> >>need to rebuild all your XS backed modules.
> >>
> >>So being able to reproduce the exact same versions of modules
> >>over time would still be needed.
> >>
> >>On Wed, Mar 02, 2016 at 09:41:41PM +0100, Lasse Makholm wrote:
> >>>On Wed, Mar 2, 2016 at 9:23 PM, 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.
> >>>>
> >>>FWIW, I looked into all of those for $work and ended up just using
> >>>local::lib and cpanm to install dependencies into a directory tracked in a
> >>>git repository. The repo has 3 branches; dev, staging and production
> >>>corresponding to our environments. So to promote something, just merge from
> >>>e.g. staging to production. Whenever we deploy a new version we just do a
> >>>git pull in the CPAN repo on all boxes geting the new release. I'm quite
> >>>happy with the setup. Adding new dependencies, tracking changes, etc, is
> >>>super easy (assuming you know git). CHANGES files etc are nice, but the
> >>>ability to to just run git diff after updating something to see exactly
> >>>what changed is invaluable IMO. Additionally, cpanm's ability to install
> >>>from e.g. git(hub) repos makes it super easy to install custom forks of
> >>>CPAN modules.
> >>>
> >>>/L
> >>>
> >>>
> >>>>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/
> >>>>
> >
> >
> >
> >_______________________________________________
> >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