[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" <tleffler at uw.edu>
To: "The elegant MVC web framework" <catalyst at 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 -0000, Andrew wrote:
>> ---> Really looking to keep it simple stupid, to be fair.
>>
>> ---> Looks like a lot to learn atm, so am likely to just copy and paste
>> folders for the time being.
>>
>> ---> I got a bit confused here:
>>
>> As a baby-step prior to doing builds and auto deployment, you can
>> checkout your code from your production server(s).  While this is still
>> a manual step, it's probably better than copying folders and files.
>>
>> ---> If you're not doing an auto deployment, and you're not copying
folders
>> and files, how are you checking out your code from the production server?
>>
>> Grateful for all the insights,
>>
>> Yours,
>> Andrew.
>>
>>
>>
>> ----- Original Message -----
>> From: "Trevor Leffler" <tleffler at uw.edu>
>> To: "The elegant MVC web framework" <catalyst at lists.scsys.co.uk>
>> Sent: Wednesday, March 02, 2016 6:54 PM
>> Subject: Re: [Catalyst] From Development to Production.
>>
>>
>> Yes, that.  But to be a tad verbose about it...
>>
>> Use version control and branches (or whatever your VCS prefers).  Cut a
>> new branch whenever you want to create a new "release" for production.
>> This will let you switch from one branch to the next (upgrade) or back
>> again if things blow up.
>>
>> As a baby-step prior to doing builds and auto deployment, you can
>> checkout your code from your production server(s).  While this is still
>> a manual step, it's probably better than copying folders and files.
>>
>> Once you're there, start looking into "builds."  Generally folks use
>> some kind of Continuous Integration (CI) software that polls your VCS
>> for recent commits and then "kicks off a build."  The simplest thing it
>> might do is checkout the latest code revision and tar it up.  This
>> tarfile is a "build artifact" ready for you to deploy (i.e. copy into
>> production and untar).  Your work after this point is to figure out what
>> else you'd like to happen during a build -- run tests? create
>> documentation? do code inspections? -- and research how your build
>> artifacts could be automatically deployed.
>>
>> I'll echo Toomas in that there's a lot to learn here and keep you busy
>> depending on how far you want/can take it.
>>
>> Cheers,
>> --Trevor
>>
>>
>> On 03/02/2016 10:32 AM, Toomas Pelberg wrote:
>>> Go learn about version control and deployment automation, you can google
>>> these keywords and will likely be busy for the next few weeks ;-) it's a
>>> pretty wide and interesting reading
>>> ------------------------------------------------------------------------
>>> From: Andrew <mailto:catalystgroup at unitedgames.co.uk>
>>> Sent: ‎3/‎2/‎2016 20:17
>>> To: The elegant MVC web framework <mailto:catalyst at lists.scsys.co.uk>
>>> Subject: [Catalyst] From Development to Production.
>>>
>>> So, I'm trying to learn Modern Perl workflows,
>>> and I heard it's best to do all your development on a development
server,
>>> rather than mess around with code live, on the production server.
>>> So let's say I've coded my Catalyst app on a dev server, and it's in a
>>> folder called MyApp....
>>> Do I just copy the MyApp folder to the Production Server?
>>> [Am likely to copy and paste the folder using Cyberduck].
>>> I mean, assuming the production server is setup to run it, and so
forth...
>>> Let's for example say, I'd already published Version 1.0 of my website
>>> on the production server.
>>> And it's running from a MyApp directory on the production server.
>>> Then I code a version 2.0 on my development server, in a folder called
>>> MyApp, and I want to publish that....
>>> ...do I just again, copy MyApp from my development server, over to my
>>> production server?
>>> Obviously, new files would overwrite old ones.
>>> What about if version 2.0 saw me delete some old unused stuff, do I have
>>> to make a note of what they were,
>>> and go through the folder on the production server and delete them?
>>> Or is there some graceful way to sync the development and production
>>> versions of my code?
>>> What are other people doing?
>>> Grateful for any insights.
>>> Yours,
>>> Andrew.
>>>
>>>
>>> _______________________________________________
>>> List: Catalyst at lists.scsys.co.uk
>>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>>> Searchable archive:
>> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>>> Dev site: http://dev.catalyst.perl.org/
>>>
>>
>> _______________________________________________
>> List: Catalyst at lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>>
>>
>>
>> _______________________________________________
>> List: Catalyst at lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>
>

_______________________________________________
List: Catalyst at lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/