[Catalyst] From Development to Production.

Toomas Pelberg igavus at gmail.com
Thu Mar 3 08:39:03 GMT 2016 

This is more or less true, but DO read the changelogs because it can and will bite you.

-----Original Message-----
From: "Jorge Gonzalez" <jorge.gonzalez at daikon.es>
Sent: ‎3/‎3/‎2016 10:34
To: "catalyst at lists.scsys.co.uk" <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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/catalyst/attachments/20160303/6ae0e909/attachment.htm>

More information about the Catalyst mailing list