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

[Dominic Mitchell]

On Wed, Aug 09, 2006 at 03:45:03PM +0100, Nik Clayton wrote:
> Tielman de Villiers wrote:
> >How about using "cp" for release management? So you use a VCS for
> >development, but when deploying the code to a staging/production
> >environment, you tar it up, copy it over and and untar in the
> >deployment directory.
> >
> >Good, bad or scary?  (Presuming a trusted and private network, so
> >security is not the issue here.)
> 
> Scary.  There's still no easy way to rollback production to a previous 
> working copy of the code.

I like the rails (capistrano) idea of symlinking to the current exported
version of the code.

> 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.  ;-)

> To keep this vaguely on topic, it's a royal pain trying to support 
> multiple versions of Perl modules with this.  All the ease of use of 
> CPAN goes out the window.

Hear, hear.  Not only that, even something as simple as pegging versions
is beyond CPAN.pm...

-Dom

[1] Using a sensible build script so it's all automatic and repeatable.
Doing it by hand would be a very bad idea indeed.