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:[email protected]> > >Sent: 3/3/2016 10:34 > >To: [email protected] <mailto:[email protected]> > >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<[email protected]> 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"<[email protected]> > >>>>>To: "The elegant MVC web framework"<[email protected]> > >>>>>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:[email protected]> > >>>>>>Sent: 3/2/2016 20:17 > >>>>>>To: The elegant MVC web framework<mailto:[email protected]> > >>>>>>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:[email protected] > >>>>>>Listinfo:http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > >>>>>>Searchable archive: > >>>>>http://www.mail-archive.com/[email protected]/ > >>>>>>Dev site:http://dev.catalyst.perl.org/ > >>>>>> > >>>>>_______________________________________________ > >>>>>List:[email protected] > >>>>>Listinfo:http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > >>>>>Searchable archive: > >>>>http://www.mail-archive.com/[email protected]/ > >>>>>Dev site:http://dev.catalyst.perl.org/ > >>>>> > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>List:[email protected] > >>>>>Listinfo:http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > >>>>>Searchable archive: > >>>>http://www.mail-archive.com/[email protected]/ > >>>>>Dev site:http://dev.catalyst.perl.org/ > >>>>-- > >>>>James R. Leu > >>>>[email protected] > >>>> > >>>>_______________________________________________ > >>>>List:[email protected] > >>>>Listinfo:http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > >>>>Searchable archive: > >>>>http://www.mail-archive.com/[email protected]/ > >>>>Dev site:http://dev.catalyst.perl.org/ > >>>> > > > > > > > >_______________________________________________ > >List: [email protected] > >Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > >Searchable archive: http://www.mail-archive.com/[email protected]/ > >Dev site: http://dev.catalyst.perl.org/ > -- James R. Leu [email protected] _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
