thinking in geek tagline’s are so web2.0

A deployment process

I know I said my next post would be my deployment script but after posting - I realised that I should do a 1000 foot overview of what I’m trying to achieve.

For me - a successful deployment has a number of components:

• Build
  1. Code successfully builds 
  2. tests pass.
• Versioning
  1. I know exactly which revision was deployed from subversion.
  2. I know what environment it was deployed to.
• Deployment Safety

  1. On my server I have the ability to rollback a deployment.

• Support
  1. I can compare the current deployed version to previous releases when I need to do post-deployment production debugging.

To achieve this I use a number of conventions which I’ve borrowed and adapted from Capistrano.

My Subversion repository is structured so that every release get’s it’s own tag - including the environment which the release was made to¹ :

The tags are kind of self explanatory - the format is:

[environment]-YYYYMMDDHHMMSSMS 

This is much easier than trying to remember that version 2.54.33.2 was released on Tuesday to client X.

In a deployment environment (staging or live) - each release is unpacked into it’s own folder.²

After a deployment package has been unpacked on the server there will be a new folder for the release. Making a release active involves a couple of (currently) non-automated steps:

1. Updating the database connection details (this is a matter of copying a database.config into the release folder³ ). 
2. running a DB upgrade
3. changing the webroot in IIS

People who are paying attention will notice that this process is not necessarily atomic. Depending on the DB changes - it’s possible that the old/new code cannot run on the same database - in this case I drop a app_offline.htm - into the previous release folder before I run the DB upgrade.

1. The folders in /tags are client names. This is because our SaaS app is released per-client - not multi tenanted. i.e. Each client is running a different version at any given time - and is upgraded to the latest trunk as necessary. [↩]
2. The occluded bits are the client name - this is for convenience in managing release packages (zip files) as the server has a folder for each client [↩]
3. this is the only thing on the server which is not versioned in subversion. My web.config has the following: <connectionStrings configSource=”database.config”/> - this file just contains the connection details for the application. [↩]