Re: [Catalyst] From Development to Production.

[Bill Moseley]

On Wed, Mar 9, 2016 at 7:35 AM, Dermot  wrote:

I want to caution you, in the nicest possible way. Writing software
> requires a number of skills and a lot of research and learning. You can't
> avoid the latter. What may seem like a lot of unnecessary aggravation
> (testing and version control) have come about because it's no fun fixing
> problems after the event.
>

Very true.

Andrew, there's an overwhelming amount of reading on this topic. If you
think there's *any* chance that your app will grow in usage and developers
over time then it's well worth planning ahead.  Automate *everything* from
the start.   It's critical to make deployments fast, repeatable, and dead
simple.   Probably should also include "scalable" there as a good buzzword.

Here's a few random links to get you thinking:

http://12factor.net/
https://zachholman.com/posts/deploying-software
https://guides.github.com/introduction/flow/ (we do a modified version of
this)

The bottom line is you want to be spending your energy on the application
functionality and not on deploying and running the application -- which
seems to consume time exponentially if not careful.


To be honest we have not really found a perfect way of managing Perl
dependencies.   I think the standard Perl module versioning system falls
apart when there's lots of developers, many "apps" involved, and a version
control system.  Our single app turned into many Catalyst apps that (with
the goal of)  have "thin" controllers and many models.  Those models were
originally separate Dist::Zilla Perl distributions in our local DarkPAN.
As those were updated with new version numbers the apps were also updated
to depended on those.   This breaks down when using Git and heavy use of
branches because versions are no longer linear -- instead small features
and fixes are merged individually.

We have swung quite far the other way now and moving toward separate repos
for each "app" and even copying the same module into multiple repos to
promote decoupling (and the cost of code duplication).   We are also using
Carton to lock down versions and bundle dependencies.

We have also put Perlbrew into Git with mixed results.I'm not a big fan
of placing build artifacts into Git, but having the entire app in a single
repo does have benefits.

We would like to get to a CI pipeline that generates a Docker container and
use that for all non-dev deployments.  You never know when you will need to
deploy a million containers ...



-- 
Bill Moseley
mose...@hank.org
___
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.

[Andrew]

  I'd suggest these files are the Model part of MVC and you should have a Class 
that you use to interact with files. This Class is independent of you Catalyst 
App and should be able to run in it's own right. Page 135 of the book 
discussing Database model because that's the common model but there are model 
class for working with files[1]. There are several references in the book to 
testing. Testing, along with software versioning are part of the tool-set 
you'll want to become familiar with if your going to be writing software. You 
could take a look at the advent calendar articles [2], they are not that 
up-to-date but useful none the less I'd say.

  ---> I have actually found a lot of the advent calendar articles really 
useful. I was shocked there weren't any for 2015 though, =P. Did we forget to 
do it last year / weren't there any volunteers? 


  Using a database would adios your permissions problems too. If you just want 
to sort out permissions problems, you could have the files/directories owned by 
the same user that runs you web server or do something fancy with suexec. 

  ---> UPDATE: Oh...do you mean the root user?
  ---> BEFORE-UPDATE: The trouble I experienced with having it owned by the 
user associated with the web domain was that there were two users needing to 
access it.
  However, what I've done for a quick fix until I can figure out a better 
solution, is thrown...
  umask ;
  ...into the appname.pm file, and now when I create directories with 0777 
permissions, as in a line like: 
  mkdir $my_data_folder_path."new_directory_we_are_making/", 0777;
  ...they're accessible to both users,
  and to enable file reading and writing, I'm just using Path::Tiny's slurp and 
spew - spew solving the access/permission problem, where append would not.
  So now I've got a quick fix allowing me to get cracking with my work,
  and then I'll read and research on the side how to improve it / what the 
better ways of doing it are.

  I want to caution you, in the nicest possible way. Writing software requires 
a number of skills and a lot of research and learning. You can't avoid the 
latter. What may seem like a lot of unnecessary aggravation (testing and 
version control) have come about because it's no fun fixing problems after the 
event.

  ---> Yes, I apologise some of the way I wrote came across as impatient, =). 
I'm excited to learn, and to reap the long term benefits, =). 


  You could also look at Dancer2 [3] as that be good fit too.

  ---> Thanks for the tip!

  Good luck,
  Dermot.

  ---> Many thanks for the page numbers I can flick to, and the links I can 
visit, =). Grateful!



  1) https://metacpan.org/pod/Catalyst::Model::File
  2) http://www.catalystframework.org/calendar/
  3) https://metacpan.org/pod/distribution/Dancer2/script/dancer2




  On 9 March 2016 at 13:26, Andrew  wrote:





  It sounds to me like you should treat these text files as the data model 

  ---> Are you suggesting I do something to them, or is this just a 
linguistic point about what to call or refer to the data as?
  I'm new to Catalyst and previously coded in procedural perl, where I 
always used a policy of: data - processing - layout.
  I equate that to Catalyst's Model - Controller - View. However, my data 
was always text files, my processing was cgi scripts, and my layout was always 
html templates.
  I now code with my processing as subroutines within *.pm files within 
Catalyst's Controller folder,
  however I haven't touched the View or Model folders - am still reading in 
html templates, substituting values, and spitting them out as the response to 
the browser - all within my controllers - it's processing after all.

  In short, I'm happy to call my text files the data model, where before I 
would have called them the data.
  However - are you suggesting I do anything?

  and yes, do not check it in to your repo.

  ---> I have no idea what repo is. Do you mean repository, for a 
versioning system? Atm, my versioning system is to download the lib folder from 
the dev server using Cyberduck, and put it in a folder on my computer hard 
drive - the folder having a version number. Then I can upload whatever version 
I want to the production server - normally the lib from the latest version 
folder created. 

   Rather create a model class to access it
  ---> I will have to research how to do this. My resources include google 
search, and the Definitive Guide to Catalyst book.

   and configure the path in you config file.
  ---> At present, I am reading the path in from a separate text file.

   When it comes to testing you are going to have to create a sample of 
those text files under the t/ directory.

  ---> Still learning Catalyst and haven't touched testing. I generally 
don't get it. Either a web app works, or is broken. I don't get writing code to 
test if code works. Comes across 

Re: [Catalyst] From Development to Production.

[Dermot]

META: my reply including the list but was bounced because my default email
address was not the one I subscribed with.


I'd suggest these files are the Model part of MVC and you should have a
Class that you use to interact with files. This Class is independent of you
Catalyst App and should be able to run in it's own right. Page 135 of the
book discussing Database model because that's the common model but there
are model class for working with files[1]. There are several references in
the book to testing. Testing, along with software versioning are part of
the tool-set you'll want to become familiar with if your going to be
writing software. You could take a look at the advent calendar articles
[2], they are not that up-to-date but useful none the less I'd say.

Using a database would adios your permissions problems too. If you just
want to sort out permissions problems, you could have the files/directories
owned by the same user that runs you web server or do something fancy with
suexec.

I want to caution you, in the nicest possible way. Writing software
requires a number of skills and a lot of research and learning. You can't
avoid the latter. What may seem like a lot of unnecessary aggravation
(testing and version control) have come about because it's no fun fixing
problems after the event.

You could also look at Dancer2 [3] as that be good fit too.
Good luck,
Dermot.


1) https://metacpan.org/pod/Catalyst::Model::File
2) http://www.catalystframework.org/calendar/
3) https://metacpan.org/pod/distribution/Dancer2/script/dancer2


On 9 March 2016 at 13:26, Andrew  wrote:

>
>
>
>
> It sounds to me like you should treat these text files as the data model
>
> ---> Are you suggesting I do something to them, or is this just a
> linguistic point about what to call or refer to the data as?
> I'm new to Catalyst and previously coded in procedural perl, where I always
> used a policy of: data - processing - layout.
> I equate that to Catalyst's Model - Controller - View. However, my data
> was always text files, my processing was cgi scripts, and my layout was
> always html templates.
> I now code with my processing as subroutines within *.pm files within
> Catalyst's Controller folder,
> however I haven't touched the View or Model folders - am still reading in
> html templates, substituting values, and spitting them out as the response
> to the browser - all within my controllers - it's processing after all.
>
> In short, I'm happy to call my text files the data model, where before I
> would have called them the data.
> However - are you suggesting I do anything?
>
> and yes, do not check it in to your repo.
>
> ---> I have no idea what repo is. Do you mean repository, for a versioning
> system? Atm, my versioning system is to download the lib folder from the
> dev server using Cyberduck, and put it in a folder on my computer hard
> drive - the folder having a version number. Then I can upload whatever
> version I want to the production server - normally the lib from the latest
> version folder created.
>
>  Rather create a model class to access it
> ---> I will have to research how to do this. My resources include google
> search, and the Definitive Guide to Catalyst book.
>
>  and configure the path in you config file.
> ---> At present, I am reading the path in from a separate text file.
>
>  When it comes to testing you are going to have to create a sample of
> those text files under the t/ directory.
>
> ---> Still learning Catalyst and haven't touched testing. I generally
> don't get it. Either a web app works, or is broken. I don't get writing
> code to test if code works. Comes across as some sort of coding narcissism.
>
> Having said that, you should probably find a way to use a database. It
> sounds to me like your data would fit nicely into a database and your
> permissions problems to be less significant.
>
> ---> Yes, I've painless experience of connecting to a MySQL database. I
> just hoped I could use Catalyst whilst working in the same simple way I
> worked before, where turn around was very fast. I just have one small task
> to accomplish, and some files seemed the easiest quickest way to do it, and
> I've hit all these permission problems, and I just thought it must be such
> a common problem, someone is bound to have solved it - so I thought to ask
> the group.
>
> ---> Right now my solution is super simple - just use spew, and avoid
> using append.
>
> ---> If there's any advice or tutorials on how to sort out permissions, or
> how to use text files as your model in Catalyst, I'd appreciate it.
>
> Hope that helps,
>
> ---> It was insightful, and has given me something to research. Right now
> I don't understand enough about how Catalyst works to know what creating a
> model class involves, and if it will solve the permissions problem, or if
> it was just mentioned as a way of putting the data folder's path into the
> config file. I shall look into it, and 

Re: [Catalyst] From Development to Production.

[Andrew]

  It sounds to me like you should treat these text files as the data model 

  ---> Are you suggesting I do something to them, or is this just a linguistic 
point about what to call or refer to the data as?
  I'm new to Catalyst and previously coded in procedural perl, where I always 
used a policy of: data - processing - layout.
  I equate that to Catalyst's Model - Controller - View. However, my data was 
always text files, my processing was cgi scripts, and my layout was always html 
templates.
  I now code with my processing as subroutines within *.pm files within 
Catalyst's Controller folder,
  however I haven't touched the View or Model folders - am still reading in 
html templates, substituting values, and spitting them out as the response to 
the browser - all within my controllers - it's processing after all.

  In short, I'm happy to call my text files the data model, where before I 
would have called them the data.
  However - are you suggesting I do anything?

  and yes, do not check it in to your repo.

  ---> I have no idea what repo is. Do you mean repository, for a versioning 
system? Atm, my versioning system is to download the lib folder from the dev 
server using Cyberduck, and put it in a folder on my computer hard drive - the 
folder having a version number. Then I can upload whatever version I want to 
the production server - normally the lib from the latest version folder 
created. 

   Rather create a model class to access it
  ---> I will have to research how to do this. My resources include google 
search, and the Definitive Guide to Catalyst book.

   and configure the path in you config file.
  ---> At present, I am reading the path in from a separate text file.

   When it comes to testing you are going to have to create a sample of those 
text files under the t/ directory.

  ---> Still learning Catalyst and haven't touched testing. I generally don't 
get it. Either a web app works, or is broken. I don't get writing code to test 
if code works. Comes across as some sort of coding narcissism.

  Having said that, you should probably find a way to use a database. It sounds 
to me like your data would fit nicely into a database and your permissions 
problems to be less significant.

  ---> Yes, I've painless experience of connecting to a MySQL database. I just 
hoped I could use Catalyst whilst working in the same simple way I worked 
before, where turn around was very fast. I just have one small task to 
accomplish, and some files seemed the easiest quickest way to do it, and I've 
hit all these permission problems, and I just thought it must be such a common 
problem, someone is bound to have solved it - so I thought to ask the group.

  ---> Right now my solution is super simple - just use spew, and avoid using 
append.

  ---> If there's any advice or tutorials on how to sort out permissions, or 
how to use text files as your model in Catalyst, I'd appreciate it. 

  Hope that helps,

  ---> It was insightful, and has given me something to research. Right now I 
don't understand enough about how Catalyst works to know what creating a model 
class involves, and if it will solve the permissions problem, or if it was just 
mentioned as a way of putting the data folder's path into the config file. I 
shall look into it, and hopefully won't be ignorant for too much longer.

  ---> And thanks for getting back to me! =D

  ---> Yours,
  ---> Andrew.

  Dermot.









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

[Andrew]

Does anyone have any advice?
Looking for the best way to handle permissions.

My web app stores data to text files, in a directory.

While it makes sense to have a development server, and a production  
server, when it comes to updating the scripts in the lib folder it  
doesn't make much sense to duplicate the data folder with all the text  
files between development and production servers.
Mainly because users using the web app will be generating data that is  
saved there, so the production server's data folder will always be  
more relevant/populated - we don't want to overwrite user data all the  
time.


So, if data is stored in a data folder on the production server,
I need a system whereby

The Production Server can:
Read and write to a file it creates.
Read a file the Dev Server created.
Write to a file the Dev Server created.

and where...

The Development Server can:
Read and write to a file it creates.
Read a file the Production Server created.
Write to a file the Production Server created.

I was taught Path::Tiny is the best plugin to use in Catalyst for  
reading and writing to files (let me know if you recommend any others).


With that, I found:

path($datapath."test.txt")->spew_utf8($bitofdata);
worked, because spew creates a temporary file and then overwrites  
the old one. This means, after the Dev server writes to the file, it  
has ownership and group permissions of the Dev server, and after the  
Production server writes to the file, it has ownership and group  
permissions of the Production server.


path($datapath."test.txt")->append_utf8($newbitofdata);
...however, which attempts to open an existing file and add an extra  
line, results in an error - permission is denied.
I assume that's because the Prod user can't access files owned by the  
Dev user, and vice versa.


So should I use spew always, or is there a way to sort out the permissions?
So that both users on the server can read and write to files in the  
data directory?


Or is there a way for the Dev Server to interact with files using the  
Prod server's userid instead of the dev server userid?


I managed to find some lines on the internet saying how to create a  
group, add users to the group, and then set ownership and group of  
files and folders. Trouble is, any new files or folders I then create  
in my Perl script, are owned by the userid associated with the server  
that created them.


What's the best practice?
To give a prod and dev server, equal access to a directory on the  
production server?


Server is a shared hosting VPS, with multiple user directories. One of  
these user directories is the development server, the other is the  
live website. Server is Apache / CentOS.


Many thanks in advance,

Yours,
Andrew


___
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 <mailto:jorge.gonza...@daikon.es>
Sent: ‎3/‎3/‎2016 10:34
To: catalyst@lists.scsys.co.uk <mailto: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<j...@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 th

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 <mailto:jorge.gonza...@daikon.es>
> >Sent: ‎3/‎3/‎2016 10:34
> >To: catalyst@lists.scsys.co.uk <mailto: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<j...@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

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 <mailto:jorge.gonza...@daikon.es>
Sent: ‎3/‎3/‎2016 10:34
To: catalyst@lists.scsys.co.uk <mailto: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<j...@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

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" <jorge.gonza...@daikon.es>
Sent: ‎3/‎3/‎2016 10:34
To: "catalyst@lists.scsys.co.uk" <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 <j...@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 -, 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" <tleff...@uw.edu>
To: "The elegant MVC web framework" <catalyst@lists.scsys.co.uk>
Sent: Wed

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 <j...@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 -, 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" <tleff...@uw.edu>
To: "The elegant MVC web framework" <catalyst@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

Re: [Catalyst] From Development to Production.

[James Leu]

We've solved these problems for our environement, but I was not willing to
go into that level of detail

Your suggestion validated how we're doing it,
so thank you for your feedback.

On Thu, Mar 03, 2016 at 07:31:08AM +1100, Kieren Diment wrote:
> As far as managing your perl/cpan version goes here's one low friction
> solution:
> 
> 1.  Make sure your dev box and production box are the same architecture.
> 2.  Use perlbrew or similar to install a perl to /opt/perl
> 3.  Copy the /opt/perl directory  between development and production
> (rsync, make a deb and dpkg -i or whatever).
> 4.  Make sure your PATH environment variables are set correctly.
> 
> On Thu, Mar 3, 2016 at 7:23 AM, James Leu <j...@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.
> >
> > 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" <tleff...@uw.edu>
> > > To: "The elegant MVC web framework" <catalyst@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

Re: [Catalyst] From Development to Production.

[James Leu]

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 <j...@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 -, 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" <tleff...@uw.edu>
> > > To: "The elegant MVC web framework" <catalyst@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 y

Re: [Catalyst] From Development to Production.

[Andrew]

and I don't want any "different versions
of dependencies" bugs wasting my time.

=)

https://www.youtube.com/watch?v=tHioEC9itTg


- Original Message -
From: "Trevor Leffler" <tleff...@uw.edu>
To: "The elegant MVC web framework" <catalyst@lists.scsys.co.uk>
Sent: Wednesday, March 02, 2016 8:40 PM
Subject: Re: [Catalyst] From Development to Production.


+1 for Carton for managing perl application dependencies.

Also perlbrew or plenv for using your own perl / separating your app
from the system perl.

I agree whole-heartedly with James regarding being able to stabilize
your app's environment and being able to consistently reproduce it.
Whether I'm spinning up a new prod server or getting a new developer up
and running, I want a [near] push-button method for getting the app
running as quickly as possible, and I don't want any "different versions
of dependencies" bugs wasting my time.

--Trevor


On 03/02/2016 12: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.
>
> 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" <tleff...@uw.edu>
>> To: "The elegant MVC web framework" <catalyst@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 f

Re: [Catalyst] From Development to Production.

[Andrew]

Oooh...ta for this.

Atm, the development and production servers are the same server - it's a VPS
server.
Because I don't understand the jargon (Do I say it's one shared hosting
solution with multiple virtual hosts?) I'll just put it plainly - one ip
address with lots of folders, each for a different domain name, and the
development server is a folder not linked to any domain name, and the
production server is a folder tied to a domain name. They both work from the
same Perl installation - installed via Perlbrew to a shared opt/ folder that
all users can access.


- Original Message -
From: "James Leu" <j...@mindspring.com>
To: "The elegant MVC web framework" <catalyst@lists.scsys.co.uk>
Sent: Wednesday, March 02, 2016 8:23 PM
Subject: Re: [Catalyst] From Development to Production.


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.

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" <tleff...@uw.edu>
> To: "The elegant MVC web framework" <catalyst@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:catalystgr...@unitedgames.co.uk>
> > Sent: ‎3/‎2/‎2016 20:17
> > To: T

Re: [Catalyst] From Development to Production.

[Lasse Makholm]

On Wed, Mar 2, 2016 at 9:23 PM, James Leu <j...@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 -, 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" <tleff...@uw.edu>
> > To: "The elegant MVC web framework" <catalyst@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,
>

Re: [Catalyst] From Development to Production.

[Trevor Leffler]

+1 for Carton for managing perl application dependencies.

Also perlbrew or plenv for using your own perl / separating your app 
from the system perl.


I agree whole-heartedly with James regarding being able to stabilize 
your app's environment and being able to consistently reproduce it. 
Whether I'm spinning up a new prod server or getting a new developer up 
and running, I want a [near] push-button method for getting the app 
running as quickly as possible, and I don't want any "different versions 
of dependencies" bugs wasting my time.


--Trevor


On 03/02/2016 12: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.

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" <tleff...@uw.edu>
To: "The elegant MVC web framework" <catalyst@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:catalystgr...@unitedgames.co.uk>
Sent: ‎3/‎2/‎2016 20:17
To: The elegant MVC web framework <mailto:catalyst@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 producti

Re: [Catalyst] From Development to Production.

[Kieren Diment]

As far as managing your perl/cpan version goes here's one low friction
solution:

1.  Make sure your dev box and production box are the same architecture.
2.  Use perlbrew or similar to install a perl to /opt/perl
3.  Copy the /opt/perl directory  between development and production
(rsync, make a deb and dpkg -i or whatever).
4.  Make sure your PATH environment variables are set correctly.

On Thu, Mar 3, 2016 at 7:23 AM, James Leu <j...@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.
>
> 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" <tleff...@uw.edu>
> > To: "The elegant MVC web framework" <catalyst@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
> > >
> 

Re: [Catalyst] From Development to Production.

[James Leu]

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.

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" <tleff...@uw.edu>
> To: "The elegant MVC web framework" <catalyst@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:catalystgr...@unitedgames.co.uk>
> > Sent: ‎3/‎2/‎2016 20:17
> > To: The elegant MVC web framework <mailto:catalyst@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.
> >

Re: [Catalyst] From Development to Production.

[Trevor Leffler]

On 03/02/2016 11:04 AM, 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?


Maybe a typo there: "check out code *to* your prod server".  The code 
would live in a repository somewhere else.


Once you have your code safely in version control (e.g. git, 
subversion), you can check out that code to wherever you want.  So while 
yes, technically, files are being copied from *somewhere* into your 
production environment, you're using a tool to fetch them from your code 
repository and telling it exactly which branch/revision of those files 
you want.  To me, this is a safer, more repeatable way of 
up-/down-grading my production application.


You could also tar/zip up your app folder, copy that over, untar it. 
You'd manage the tars/zips yourself, maybe naming them myapp-0.01, 
myapp-0.02, or whatever.


Really, look into version control for your software projects.  You'll 
thank yourself and never look back.


Best,
--Trevor


Grateful for all the insights,

Yours,
Andrew.



- Original Message -
From: "Trevor Leffler" <tleff...@uw.edu>
To: "The elegant MVC web framework" <catalyst@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:catalystgr...@unitedgames.co.uk>
Sent: ‎3/‎2/‎2016 20:17
To: The elegant MVC web framework <mailto:catalyst@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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable

Re: [Catalyst] From Development to Production.

[Andrew]

---> 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" <tleff...@uw.edu>
To: "The elegant MVC web framework" <catalyst@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:catalystgr...@unitedgames.co.uk>
> Sent: ‎3/‎2/‎2016 20:17
> To: The elegant MVC web framework <mailto:catalyst@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@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@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@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.

[Trevor Leffler]

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:catalystgr...@unitedgames.co.uk>
Sent: ‎3/‎2/‎2016 20:17
To: The elegant MVC web framework <mailto:catalyst@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@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@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.

[Toomas Pelberg]

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

-Original Message-
From: "Andrew" <catalystgr...@unitedgames.co.uk>
Sent: ‎3/‎2/‎2016 20:17
To: "The elegant MVC web framework" <catalyst@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@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/