[Gllug] Practical release and deployment - how?

[Aaron Trevena]

On 07/11/2007, Karanbir Singh <mail-lists at karan.org> wrote:
> I think deploying moving code using rpm isnt the best way really. Its a
> lot better to have a deployment / push process where you can push real
> code and changesets to production machines, wrap them with rollout tests
> and have direct control on that.

I've just finished a contract where we moved to deploying via debian
packages - once we got the large backlog of legacy stuff and cpan
dependancies sorted it was pretty smooth going.

We used SVN but didn't require much branching as there was little
concurrency beyond working as a team on something, releases were
packaged nicely with a changelog, usually based on a CPAN style
package with an SVN revision number in both the perl and debian
package changelog.

Currently I'm trying to sort out a mess where a client has a bunch of
servers (none of which can really be used for staging) and all the
code, html, etc is in cvs working directorys with deployment done via
cvs update -dP filename - no tags, no branches, no change log, no
release notes, on top of that there are uncommitted changes on the
servers as well.

At this point I'm thinking they really need to get a spare server to
use for staging and update it to an export of a known working,
complete and tagged  set of files, and take each of the existing
servers out of the load balanced pool in turn updating it to match the
staging server and returning it to the pool again.

Anybody advocating cvs update as a sane or suitable way of deploying
anything to servers deserves a good kicking. (I may not be in the best
of moods right now)

A.

-- 
http://www.aarontrevena.co.uk
LAMP System Integration, Development and Hosting
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug