Catalyst deployment headscratchings

[stonecolddevin]

Dear Monks,

I have a question about deploying Catalyst apps.

I've tried various methods, but they've either been "unprofessional", or pretty much sloppy.

Currently, I do an svn export of my working copy, tar/gz that all up, SFTP to my server, uncompress, and fiddle to get things working (namely, chmod +x dispatch.fcgi, perl script/myapp_deploy_schema.pl, etc.).

This still seems a bit clunky to me, and being fairly new to a polished deploy process, I was wondering if any experts had any advice, as this process lends itself to a few errors including a bit of a lengthy process to do the aforementioned steps, as well as some of the annoying fiddling/fenaggling to get things working properly.

Does anyone else have a more refined process?

-dhoss

[almut]

What you describe doesn't sound too unprofessional to me. The only thing that I'd consider "unprofessional" is doing all the steps by hand every time... After all, Perl is the perfect glue language for automating such tasks, in particular in real-world situations, where things are often somewhat ugly due to the various idiosyncrasies of the deployment environment (which are sometimes beyond your immediate control).

[jplindstrom]

That doesn't sound too terrible, except for the manual fiddling. That's terrible :)

Start off with a manual process, but, three strikes and then you automate. Especially important and error prone and stressful things like making a release and deploying it to an environment (release and deployment are two different things). It should be as effortless as running a script with some config options.

We use Templare Toolkit to generate config files (e.g. httpd.conf) from templates, with current release and deployment values.

You should have a process in place (and by process I mean a checklist of what needs to be done, and scripts to automate anything automatable), maybe on a Wiki page. There are probably non technical steps here: telling people before and after the upgrade, assembling a set of release notes, updating the list of what's deployed where (unless you automated that too).

The only thing in your description that sounds odd is exporting the working copy. Wouldn't it be better to base the release of a clean check out to a temp directory, so you're 100% certain it contains what's in the repo and nothing else?

/J

[andreas1234567]

Wouldn't it be better to base the release of a clean check out to a temp directory, so you're 100% certain it contains what's in the repo and nothing else?

I agree. Additionally, I would do a svn copy to tag the release.

When using cvs it could look like this:

REV=MyApp-0-2-1-b
mkdir -p /tmp/$REV
cd /tmp/$REV
cvs export -r $REV MyApp
tar -cvf $REV.tar MyApp
bzip2 $REV.tar
rm -rf MyApp

I guess a similar thing is possible for subversion also.