Deployment Strategies (was: The limits of VCS (the "no good Perl jobs"/"no good Perl programmers" myth))
abs at absd.org
Wed Aug 9 17:43:28 BST 2006
On Wed, Aug 09, 2006 Dominic Mitchell wrote:
> On Wed, Aug 09, 2006 at 03:45:03PM +0100, Nik Clayton wrote:
> > I've got a release process that builds OS (Solaris in this case)
> > packages, which install in to directories that version numbers in.
> > Then there's a postinstall script that stops services (like sendmail),
> > diddles a bunch of symlinks, and starts the services again.
> > It means you can have multiple versions installed, with only one of them
> > active. If you want to make a different one active you go and run the
> > postinstall script for that version.
> O/S packages are great, but a *lot* easier in a homogenous environment.
> Once you start deploying to two, three or more operating systems, it
> starts to get frustrating.
> Generally, I find that O/S packages are great for sysadmins, but a bit
> of a nuisance for developers. I would love to see this corrected.
> Having said that, it does also encourage too much reliability on
> services provided by the Operating System. For example, what happens if
> some systems chappie comes along and hits the "Update" button? Will
> your code still work ok when (say) OpenSSL gets upgraded? Or another
> one: We want to use PostgreSQL 8.1; Debian sarge only supports 7.4.
> Yes, you can have fun with backports and so on, but to be honest, it's a
> hell of lot simpler to maintain your own $prefix containing the bits
> you want.
> I realise much of this is debatable. But deployments never seems to get
> debated much. ;-)
Pick a packaging system which work across the different
systems, installings into the same prefix (anyone who
suggests '/usr/local' wins a sharp thwack with a clue-by-four).
Having one that allows you to include local patch in the
build system is also a win.
After some initial fiddling we have a quite happy setup
across three system types (two Linux and NetBSD) for
Catalyst, postgres, apache-tomcat (I know, I know) and
friends. Previously worked on Solaris and FreeBSD but don't
have any need for those at the moment.
We have a single config file which lists the package combinations
required for each machine/machinetype, and point it to a set
of locally built binary packages to put any individual machine
into a well defined package state, backing out is using the
previous set, but thats why we have test boxes :)
We go with pkgsrc, but I think the priciple is more interesting
than the package system chosen.
Multiple installed versions of the same packages are wonderful
in some limited cases, but if you take it too far you end up with
the nightmare case of multiple 'versions' of pkga, one linked
against pkgb-1.0, another against pkgb-2.0, etc, all of which are
'pkga-1.0'. When you get into large dependency trees the number
of 'versions' of a package with the same `version` explode (as
does your head :/
Perl manages to sidestep most of the nasty ABI incompatibilites
of dependencies changing versions, but few things beat developing
and deploying on the same version :)
More information about the london.pm