[Catalyst] From Development to Production.

Andrew catalystgroup at unitedgames.co.uk
Wed Mar 2 20:43:00 GMT 2016


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


--
James R. Leu
jleu at mindspring.com

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





More information about the Catalyst mailing list