Re: Catalyst deployment headscratchings

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?

Comment on Re: Catalyst deployment headscratchings

Replies are listed 'Best First'.

Re^2: Catalyst deployment headscratchings
by andreas1234567 (Vicar) on Nov 06, 2008 at 14:33 UTC

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?

svn copy

tag

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
[download]

--
No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]

[reply]
[d/l]
[select]


P is for Practical
	PerlMonks