Re: [Catalyst] Feasibility questions ref transition to Catalyst

[Andrew]

In the end, although it's off-topic from Catalyst,
I found what I was really after in apache was:

FallbackResource /path/to/catalystapp_fastcgi.pl/

...instead of the Alias to my catalyst app.

As in:

FastCgiExternalServer /home/username/public_html/myapp/script/myapp_fastcgi.pl 
-host www.mydomain.com:56000
FallbackResource /myapp/script/myapp_fastcgi.pl/


That would mean it would try and see if a file or directory of the same name as 
that being requested existed, and only if there was no such file or directory, 
would it pass the request on to my app.
I.e. all existing cgis and static content are served as they ever were, and any 
other requests gets dealt with by the catalyst app.

Things got complicated when the path and file weren't in the public_html folder 
however - as:
FallbackResource /somethinggoeshere
essentially translates to www.mydomain.com/somethinggoeshere
...so it becomes impossible to actually specify a folder outside of the public 
html directory.
(Unless because I'm new to apache, I'm missing something?)

When my Catalyst app wasn't in public_html, and was instead at 
/home/username/myapp/script/myapp_fastcgi.pl
I used:

FastCgiExternalServer /home/username/public_html/myapp_fastcgi.pl -host 
www.mydomain.com:56000
FallbackResource /myapp_fastcgi.pl/

I get away with the first line, because FastCgiExternalServer doesn't actually 
need the file mentioned to exist - only the path needs to be real.
However, the FallbackResource bit didn't actually work, until I put a file 
called myapp_fastcgi.pl in the public_html directory.
It didn't have to have anything in it - I used a blank text file, and renamed 
it.
Bit annoying though. Don't know if I'm missing something, and there's a way of 
feeding a path to FallbackResource that isn't public html.

  - Original Message - 
  From: Andrew 
  To: The elegant MVC web framework 
  Sent: Wednesday, March 02, 2016 6:14 PM
  Subject: Re: [Catalyst] Feasibility questions ref transition to Catalyst


  I've just seen something similar on page 115 of The Definitive Guide to 
Catalyst.
  I will look into this further...

  'Cos atm, I've just got one directory working, but I pretty much want the 
entirety of public_html (all its files and subfolders, etc) back up as my 
static content, and I wonder if this is a way to do it...?
- Original Message - 
From: QE :: Felix Ostmann 
To: The elegant MVC web framework 
Sent: Wednesday, March 02, 2016 10:01 AM
Subject: Re: [Catalyst] Feasibility questions ref transition to Catalyst


Uh, i guess in some old wiki is that already mentioned. We use this for our 
static content:


Alias /static/ /path/to/static/directory
Alias / /path/to/myapp_fastcgi.pl/


And in our app we use Static::Simple with the same directory. So while 
developing only with the buildin server all works fine and later apache serves 
the static content and all works fine :)


Mit freundlichen Grüßen
Felix Ostmann


_

QE GmbH & Co. KG
Martinistraße 3
49080 Osnabrück
Deutschland

Tel.: +49 (0) 541 / 40666 11
Fax: +49 (0) 541 / 40666 22
Email: i...@qe.de
Web: www.qe.de


Unsere Geschäftszeiten:

Montag bis Freitag von 8 bis 16 Uhr

Firmensitz: Osnabrück
AG Osnabrück - HRA 200252
Steuer-Nr.: 66/204/54104
Ust-IdNr.: DE814737310

Komplementärin:
QE24 GmbH
AG Osnabrück - HRB 200359
Geschäftsführer: Ansas Meyer
_


Die in dieser Email enthaltenen Informationen sind vertraulich
zu behandeln und ausschließlich für den Adressaten bestimmt.
Jegliche Veröffentlichung, Verteilung oder sonstige in diesem
Zusammenhang stehende Handlung wird ausdrücklich untersagt.


2016-03-02 8:39 GMT+01:00 Andrew :

  Just discovered something else that's pretty cool.

  When setting up FastCGI in Apache,
  you have something like:

  
  FastCgiExternalServer
  /home/username/public_html/myapp/script/myapp_fastcgi.pl -host
  www.mydomain.com:55900
  Alias / /home/username/public_html/myapp/script/myapp_fastcgi.pl/
  

  ...in your virtual host configuation.
  (Because I have CPanel on my Apache server, I'm not editing the httpd.conf
  file directly. Rather the httpd.conf file links to some include files, so 
I
  just edit the include files.)

  I realised the Alias bit, was making any URL from the domain name, go to 
the
  Catalyst Web App.
  However I had a few old CGIs I wanted to run.
  I played about a bit, trying to copy and paste the CGI code into a new
  Catalyst Controller... but I thought: "This is too much work".

  The CGIs I wanted to run were in a directory - let's pretend the directory
  was literally called "directory".
  I added a new Alias line to this part of the Apache 

Re: [Catalyst] New view: ICal?

[Ashley Pond V]

A View is fine but because there is a format for files and it's
natural to show/deliver content with a view.

The view is going to be very THIN though. Basically nothing but a
wrapper around what iCalendar really is which is data and therefore
the Model domain. The view will essentially be Data::ICal->as_string +
Content-Type => text/calendar + file disposition name something
reasonable with a .ics or .ifb. I think the model should do all the
heavy lifting. That allows it to be easily repurposed in other places,
tools, and tests.

I'm somewhat surprised no one has already done this. Casual searches
look like maybe it's been solved before but not released to the CPAN.
I was toying with a similar project years ago but never got the buy-in
from the project leader. :P

___
List: Catalyst@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/

[Catalyst] New view: ICal?

[Chris Welch]

Hi

So as part of my sports league web site, I've been looking at adding the
ability to download matches into personal calendars.  It strikes me the
most obvious way to do this is with a view, something like
Catalyst::View::ICal - there doesn't seem to be anything like that around
at the moment, so based on the fact that I've never actually contributed
anything to CPAN before (I know that bit is beyond the scope of this list,
I'm looking into that at the moment) I'm sort of thinking it might be
something handy to add in, what do you folks think?

It should be pretty simple even for someone like me, as I think I can use
Data::ICal  to
do most of the work... but is it a reasonable idea and is a view the best
way to do it in any case?  I've had a look through the Catalyst::View::*
modules and couldn't see anything similar, which probably means the idea is
a load of rubbish or no one has had need for it yet I guess - if it's the
former I won't be offended if people tell me so... :-)

Ta


Chris
___
List: Catalyst@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/

Re: [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 
Sent: ‎3/‎3/‎2016 10:34
To: catalyst@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  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 

Re: [Catalyst] From Development to Production.

[James Leu]

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 
> >Sent: ‎3/‎3/‎2016 10:34
> >To: catalyst@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  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 

Re: [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 
Sent: ‎3/‎3/‎2016 10:34
To: catalyst@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  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 

Re: [Catalyst] From Development to Production.

[Toomas Pelberg]

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

-Original Message-
From: "Jorge Gonzalez" 
Sent: ‎3/‎3/‎2016 10:34
To: "catalyst@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  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 -, 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" 
To: "The elegant MVC web framework" 
Sent: Wednesday, March 02, 2016 6:54 PM
Subject: Re: [Catalyst] From Development to Production.


Yes, that.  

Re: [Catalyst] From Development to Production.

[Jorge Gonzalez]

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  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 -, 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" 
To: "The elegant MVC web framework" 
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