Does your project have a Heartbeat?

I often talk to people in small software shops who are violating some of the fundamental tenants of modern software development.  Today I'd like to visit a topic that everyone knows about, but few people practice properly.  And no, I'm not talking about flossing.

One of the golden rules of modern software development is that one should build all software on a dedicated build machine. 

Before you brush me off and tell me that this isn't important, let me set up a scenario.

If I hand you a Visual Source Safe database full of code, can you recreate the software project from just that database?

Ok, now, if you hand me your VSS database, (or if you are really smart, a better tool like Perforce or Vault), can I recreate your software? Many people think that once they check their code into source control, then that's all there is.

Let's take a closer look at this for a moment. Now I've got a bunch of raw code, but how do I turn that code into an executable?  I need compilers, of course.  A critical piece that many teams miss is that the build machine should be a controlled item, just like any piece of code.  Of course, you can't check in your build machine into source control, but you can come close:

A build machine should:

1.  Be well documented.  This includes Version of the Operating System, Service Pack level, HotFixes installed, Tools installed, along with any special installation instructions.

2.  Be easily reproducible.  Anyone on your development team should be able to take the documentation, the build machine, and any required installation media, and recreate that build machine on demand.  If you can't, then you don't know what exactly is in your product.

3.  Not contain a single piece of software not related to the build.  For example, just because your project uses crystal reports does not mean that you need crystal reports on the build machine.

4.  Be in an area that is controlled in its access, if at all possible.  If this is not possible, then you should control who may log onto the computer.

5.  Be under change control.  No change to the build machine should take place unless that change is documented and approved.

A build process should:

1.  Be reproducible.  You should be able to recreate any version of your product (even internal versions) at any time.

2.  Well documented.  This goes back to step one.  How can you recreate what you don't know how to do?

3.  Performed often.  Preferably daily.  More often than daily if you believe in the tenants of continuous integration.

4.  Automated to the greatest extent possible.  The less possibility for human error, the more likely you are to have a perfect reproduction of software.  Script, Script, Script!

A few things not to do:

1.  Never make the build computer a developer's workstation!

2.  Never do anything with the build computer except build that version of software.  I strongly suggest using a disk image tool such as Ghost to re-image after every build.  You don't get much more of a 'known state' than this.  This was actually very important in the VB6 / COM world.

Most modern development methodologies, including XP and the Microsoft Solutions Framework recommend that any software project be built daily on a dedicated build machine.  The daily build is often referred to as the 'heartbeat' of the project.  If the daily build isn't working, then your software project is in trouble.  You need to fix it, and fast.

--