Automated deployments #1: What’s on your server?

No really, what’s actually on your server?  If you’re first answer isn’t “erm” you’re either very good or don’t understand the question.  Servers are huge, they can store War and Peace on their hard drives without you even noticing.  For that matter, they can store any number of PDFs of books on patterns and practices without any appreciable benefit to civilization, but I don’t think that’s really the fault of the servers.  It’s practically impossible to really know what’s on there.  What’s worse, the way most people do development, they make the job harder for themselves.

I had a meeting with our auditor today and thanked my lucky stars that we had automated deployments.  Automated deployments save an awful lot of effort if they’re done right and really save your hide when people start poking around your process.  Let’s talk about a really simple question, what’s an your server?

If you tell me it’s version 1.2.6, I’m going to have a few questions.

• What was in version 1.2.6?  Is there a label in source control?
• Was every file checked in?
• What build does that correspond to?
• How can you check that the build is what got deployed?
• How about the config, is that in source control?  The actual config that’s on the server right now.
• How do you know nothing’s changed on the server since then?

Look at Microsoft, or any large company, and they’ve got this sorted out.  It’s internal development teams that tend to have a problem.  When people ask these questions:

• What’s changed since we last deployed?
• What could this affect?
• Can we rollback?

You want to have good answers.  And absolutely fundamental to this is: know what’s on your server.  Exactly.

First, you need to have a build server.  Download and love CruiseControl.NET.  Builds on local machines always turn out to have the wrong version, a reference to something that isn’t in source control, a dependency that isn’t well worked out.  A real pain for anyone starting with this is that it turns out your solution files aren’t really as flexible as you’d like.  You can get going with MSBuild, but there’s a reason every open source project uses nant.  (NAnt is far from perfect, but it’s a heck of a lot easier than MSBuild for anything slightly complex.)

Anyway, here are my answers:

• Version numbers are build numbers.  “1.2” is just for PR, it’s got nothing to do with versioning.  Call it what you like (you can call it Vista if you must) but the real version number is the build number from on the build server.
• Build Servers will only build files that are checked in.
• I said that version numbers are build numbers, right?
• We label every assembly that gets built with the build number (I stick it in the summary in the DLL).  This makes it really easy to just check the version on the server.  Also, we stick the information in an About Box, or a web service call.
• The actual config on the server isn’t in source control, but the environmental delta is.  The deployment process stamps the config with the information as well.
• Making sure that nothing’s been changed is harder, because no-one’s written a general tool for doing so, but taking a hash of the directory straight after deployment and checking it each day will catch most of that.  (You can hash files individually for better diagnostics.)  Tracking every setting on the server is probably more trouble than it’s worth, but I do have a tool for downloading IIS Virtual Directory settings to an XML file, because that turned out to be on the right side of the cost/benefit calculation.

Your answers don’t need to be the same, but I guarantee you your life will be easier when you have answers to these questions.  Importantly, the work scales.  The more people join your team, the more this stuff is important.  Incidentally, you can do all of this in TFS.  I know, I’ve done it.  And I’ve regretted not using CruiseControl.NET, NUNIT, SVN and NANT every time.  Open source, depressingly, appears to be better documented than the stuff I paid for.