(This is the third part in a series – you should probably read part one and two first.)

Today I’ll present a sanitised copy of my deployment script. I’ve based the design of deploy.cmd on Capistrano¹ . The script is nicknamed “Crappystrano”. Here’s the output (pretty htmlized source is here):

>deploy.cmd

Crappystrano – the shit script which (sort of) deploys stuff

deploy.cmd staging|live [branchpath]

Here’s breakdown of the steps² – skipping some error checking³. :

1. Do we have the required dependencies⁴ on the path? If we don’t copy them to the path if they’re just 1 exe – otherwise exit with an error.
2. Check the command line parameters. We must have the environment we’re releasing to? Are we releasing from the trunk or from a SVN branch?
3. Construct a release time stamp. This is YYYYMMDDHHMMSSMS.
4. Perform a “svn export” from the trunk/branch to %tmp%\staging|live%timestamp%. [E]
5. Use msbuild to build the solution. [E]
6. Rearrange the folder structure so we only get the artefacts we need in the release package.
7. Zip up the release package using the environment name + time stamp.
8. move the release package back to the root directory of the project and delete the export from %tmp%.
9. Make a SVN tag (svn copy trunk/branch /tags/environment-timestamp).

I’ve uploaded a zip file with the script and folder structure + a little readme. This is not the best way of doing things – it’s just a very lightweight way. Comments, questions, feedback etc… are gratefully received.

1. http://www.capify.org/ – I know some people are going to say – just use Capistrano. There are two reasons for me not to: 1. I’m the only person in my team familiar with Ruby. 2. Even if you argue that they don’t need to understand ruby to run a cap deployment recipe – they still have to have it installed. It’s just yet another dependency which I’m not willing to take currently.
2. This is all simplified as the actual script supports a SaaS product which has multiple instances – one per client
3. noted with [E]
4. gnu zip.exe, svn

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.

When it comes to web applications – most teams don’t bother automating their deployment processes. This is something that I think is in the process of changing² – but is not yet a generally accepted practice on a par with TDD, user stories or iterations.

At a minimum – it should be possible to:

1. Issue a single command which creates a release package for your project. (i.e. built, tested, tagged in subversion and zipped up). For me – this tool/command is called: deploy.cmd and is just a batch file.
2. Issue another command in your deployment environment which will configure the new release. (i.e. update IIS root, upgrade the database, update connection strings + any other configuration required).

In my current project I’ve built 1. For me 2 does not exist as a single command line (It’s currently a combination of several tools – this should be changed!).

In my next post I’ll outline my very simple solution for this. Just to get the conversation started.

1. Ten years ago – part of my job was building deployment packages for desktop applications (this is pre MSI). Identifying all the dependencies of an app and scripting them into an install package and testing the deployment was at times almost a full time job.
2. there have been a couple of good threads about this on the altnetconf mailing list