[Catalyst] From Development to Production.

[Jorge Gonzalez]

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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/catalyst/attachments/20160303/e8891d55/attachment.htm>