Deployment Strategies (was: The limits of VCS (the "no good Perl jobs"/"no good Perl programmers" myth))

[David Brownlee]

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[1].
> 
> 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 :)