[Catalyst] From Development to Production.

[Jorge Gonzalez]

El 03/03/16 a las 15:20, James Leu escribió:
> 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 ;-)

That's the point. I have development environments for CentOS 5, CentOS 6 
and CentOS 7. I rebuilt the Perl environment in each of them when I 
installed my devel environment.

After that, I have upgraded the OS in all of them, without touching the 
Perl environment.

Well, almost :-) I have sometimes rebuilt the Perl environment (i.e. 
from Catalyst 5.70 to 5.80) on the same major OS version (CentOS 5), but 
I treated the upgrade as if it were a full OS upgrade.

> Ofcourse this assumes the architecture of dev and prod are the same.
Of course. Dev and Prod should be very similar, if not identical. If 
they are not, what's the point of testing? You wouldn't be sure if 
errors would be due to bugs on your side of to differences in OS or arch.
> But realistically, does anyone use anything except x86_64?

I happen to have i686 in production from several years ago, with CentOS 
5. From the times when "4 GB RAM shoul be enough for everybody" :-D

> 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.

I have included my perl environment (tar.gz) under revision control in 
the same project, and I have several directories for each OS. I.e. 
perl/centos6, perl/centos7, perl/debian7, etc. Inside those dirs are the 
respective Perl environments for each OS.

> 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/
>