<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#ffffff"><div><div style="font-family: Calibri,sans-serif; font-size: 11pt;">This is more or less true, but DO read the changelogs because it can and will bite you.</div></div><div dir="ltr"><hr><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">From: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:jorge.gonzalez@daikon.es">Jorge Gonzalez</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Sent: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">3/3/2016 10:34</span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">To: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:catalyst@lists.scsys.co.uk">catalyst@lists.scsys.co.uk</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Subject: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">Re: [Catalyst] From Development to Production.</span><br><br></div>
This is not exact.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards<br>
J.<br>
<div class="moz-signature">
<div style="margin: 20px; color: black; float: left; font-face: Verdana;"> <span style="font-style: italic; font-weight: bold;">
Jorge González Villalonga<br>
</span> Consultor de Sistemas<br>
Red Hat Certified Engineer #140-183-666<br>
Móvil: (+34) 672 173 200<br>
</div>
<div style="clear: both;">
<div style="margin: 15px; border-radius: 10px; width: 900px; background-color: rgb(220, 220, 220); -moz-border-radius: 10px;">
<p style="padding: 10px; text-align: justify; color: rgb(85, 85, 85); font-size: 85%; font-face: Verdana;"> 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. </p>
</div>
</div>
</div>
<div class="moz-cite-prefix">El 02/03/16 a las 21:54, James Leu
escribió:<br>
</div>
<blockquote cite="mid:20160302205400.GD20788@mindspring.com" type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, Mar 2, 2016 at 9:23 PM, James Leu <a class="moz-txt-link-rfc2396E" href="mailto:jleu@mindspring.com"><jleu@mindspring.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">---> 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
</pre>
</blockquote>
<pre wrap="">folders
</pre>
<blockquote type="cite">
<pre wrap="">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" <a class="moz-txt-link-rfc2396E" href="mailto:tleffler@uw.edu"><tleffler@uw.edu></a>
To: "The elegant MVC web framework" <a class="moz-txt-link-rfc2396E" href="mailto:catalyst@lists.scsys.co.uk"><catalyst@lists.scsys.co.uk></a>
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:
</pre>
<blockquote type="cite">
<pre wrap="">Go learn about version control and deployment automation, you can
</pre>
</blockquote>
</blockquote>
<pre wrap="">google
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">these keywords and will likely be busy for the next few weeks ;-) it's
</pre>
</blockquote>
</blockquote>
<pre wrap="">a
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">pretty wide and interesting reading
</pre>
</blockquote>
</blockquote>
<pre wrap="">------------------------------------------------------------------------
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">From: Andrew <a class="moz-txt-link-rfc2396E" href="mailto:catalystgroup@unitedgames.co.uk"><mailto:catalystgroup@unitedgames.co.uk></a>
Sent: 3/2/2016 20:17
To: The elegant MVC web framework <a class="moz-txt-link-rfc2396E" href="mailto:catalyst@lists.scsys.co.uk"><mailto:catalyst@lists.scsys.co.uk></a>
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
</pre>
</blockquote>
</blockquote>
<pre wrap="">server,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
<pre wrap="">forth...
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
<pre wrap="">have
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:Catalyst@lists.scsys.co.uk">Catalyst@lists.scsys.co.uk</a>
Listinfo: <a class="moz-txt-link-freetext" href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a>
Searchable archive:
</pre>
</blockquote>
<pre wrap=""><a class="moz-txt-link-freetext" href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a>
</pre>
<blockquote type="cite">
<pre wrap="">Dev site: <a class="moz-txt-link-freetext" href="http://dev.catalyst.perl.org/">http://dev.catalyst.perl.org/</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
List: <a class="moz-txt-link-abbreviated" href="mailto:Catalyst@lists.scsys.co.uk">Catalyst@lists.scsys.co.uk</a>
Listinfo: <a class="moz-txt-link-freetext" href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a>
Searchable archive:
</pre>
</blockquote>
<pre wrap=""><a class="moz-txt-link-freetext" href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a>
</pre>
<blockquote type="cite">
<pre wrap="">Dev site: <a class="moz-txt-link-freetext" href="http://dev.catalyst.perl.org/">http://dev.catalyst.perl.org/</a>
_______________________________________________
List: <a class="moz-txt-link-abbreviated" href="mailto:Catalyst@lists.scsys.co.uk">Catalyst@lists.scsys.co.uk</a>
Listinfo: <a class="moz-txt-link-freetext" href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a>
Searchable archive:
</pre>
</blockquote>
<pre wrap=""><a class="moz-txt-link-freetext" href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a>
</pre>
<blockquote type="cite">
<pre wrap="">Dev site: <a class="moz-txt-link-freetext" href="http://dev.catalyst.perl.org/">http://dev.catalyst.perl.org/</a>
</pre>
</blockquote>
<pre wrap="">--
James R. Leu
<a class="moz-txt-link-abbreviated" href="mailto:jleu@mindspring.com">jleu@mindspring.com</a>
_______________________________________________
List: <a class="moz-txt-link-abbreviated" href="mailto:Catalyst@lists.scsys.co.uk">Catalyst@lists.scsys.co.uk</a>
Listinfo: <a class="moz-txt-link-freetext" href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a>
Searchable archive:
<a class="moz-txt-link-freetext" href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a>
Dev site: <a class="moz-txt-link-freetext" href="http://dev.catalyst.perl.org/">http://dev.catalyst.perl.org/</a>
</pre>
</blockquote>
</blockquote>
<pre wrap=""></pre>
</blockquote>
<br>
</body></html>