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

Re: [Catalyst] From Development to Production.

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" Sent: ‎3/‎2/‎2016 20:17 To: "The

Re: [Catalyst] Feasibility questions ref transition to Catalyst

I've just seen something similar on page 115 of The Definitive Guide to Catalyst. I will look into this further... 'Cos atm, I've just got one directory working, but I pretty much want the entirety of public_html (all its files and subfolders, etc) back up as my static content, and I wonder if

Re: [Catalyst] From Development to Production.

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

Re: [Catalyst] Feasibility questions ref transition to Catalyst

I heard nginx is what I should be using, yet having an apache server makes it difficult to setup!? I gather if I ever ditch my CentOS & Apache server for Amazon's cloud hosting, it's easy enough to get Ubuntu and Nginx and stuff... (I'm speaking vaguely, as I have little idea what I'm talking

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.

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

Re: [Catalyst] From Development to Production.

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

Re: [Catalyst] From Development to Production.

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

Re: [Catalyst] From Development to Production.

On Wed, Mar 2, 2016 at 9:23 PM, James Leu wrote: > It all comes down to the apps 'environment`. > > Do you remember when you started developing your catalyst app you had to > install a bunch of perl modules? > > Those same modules (preferabbly the EXACT same versions as you

Re: [Catalyst] From Development to Production.

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" To: "The elegant MVC web framework" Sent: Wednesday, March 02, 2016

Re: [Catalyst] From Development to Production.

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

Re: [Catalyst] From Development to Production.

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

Re: [Catalyst] From Development to Production.

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

Re: [Catalyst] Feasibility questions ref transition to Catalyst

Uh, i guess in some old wiki is that already mentioned. We use this for our static content: Alias /static/ /path/to/static/directory Alias / /path/to/myapp_fastcgi.pl/ And in our app we use Static::Simple with the same directory. So while developing only with the buildin server all works fine

Re: [Catalyst] Feasibility questions ref transition to Catalyst

Cool, =D. Thanks for that. - Original Message - From: QE :: Felix Ostmann To: The elegant MVC web framework Sent: Wednesday, March 02, 2016 10:01 AM Subject: Re: [Catalyst] Feasibility questions ref transition to Catalyst Uh, i guess in some old wiki is that already

Re: [Catalyst] Feasibility questions ref transition to Catalyst

I know you folks are talking about Apache, but I've used this for nginx for static content if it helps anyone (I think I'm an nginx convert now mainly because, it's extremely simple for a relative Linux newbie like me): location /robots.txt { alias /path/to/robots.txt; expires 30d; } On 2