Give your development project a heartbeat

Back in the early to mid-90's I did a fair bit of reading about Microsoft as they asserted their hold on the IT marketplace. One of the things that struck me was their use of daily builds to assert the condition of the software under construction and the mentality of always having software that was close to shipping quality. I loved the “don't break the build” mentality and started to introduce it into my projects.

What does a heartbeat involve? It's all about having your software compiled, tested and deployed in an automated way on a regular basis. This process is often referred to as 'the build'. Ten years ago, doing this once a day was considered good practice. Nowadays we run a build every time someone checks in new or updated code. Having a comprehensive build process reduces risk and provides an easy way to see how things are progressing. It also builds momentum on the team as the number of consecutive clean builds adds up.

Many projects back in the 90's were divided into multiple development streams with no integration or compilation of the whole occurring until very late in the project. Progress was tracked via written status reports, not by the presence of software that was compiled, deployed and tested every day. Custom business applications were not viewed as products that needed to be 'ready to ship' every day. Introducing the concept of a build as the heartbeat of the project helped to bring consulting teams closer to their commercial software counterparts and to take more ownership in the team 'product'.

As a project leader I like being able to check the heartbeat every day. How many builds did we run? Did the last build pass? What areas of the code did we create or modify? Did we run tests on them? Did they all pass? Being able to answer these questions in minutes every day is invaluable and lets me spend more time on the project challenges and less time on trying to figure out where we are at.

A regular heartbeat/build can also be a way to develop comraderie and have some fun on the team. Developers can sometimes cause the build/heartbeat to fail by checking in some untested code or getting sloppy in some other way. We typically have some sort of fun 'prize' linked to breaking the build and stopping the project heartbeat. This can range from a 'toque of shame' to a really big embarrassing sign that hangs over their desk. They typically have to own this until someone else breaks the build. On strong teams the stakes are high since you may wait for weeks or months for someone else to goof up and let you pass along the prize. The serious side to this is that a broken build is an 'all hands on deck' situation – we don't move on until the build has been fixed and the project heartbeat started again.

In the past several years it has become even easier to give your project a heartbeat. Tools like CruiseControl, Ant and XUnit have become defacto standards in software development and blur the traditional lines between different technologies such as Java and .NET. These tools tie together well and make it easy to automate complex build processes.

What are we doing on my current project? It's a .NET project so we use NAnt to automate the build script, NUnit for automated unit testing, Subversion for source code control and CruiseControl.NET to tie it all together and handle execution and reporting for the automated builds. We're still working a lot of issues on the business side of the project but it's nice to know the 'project heartbeat' is already going strong.

Are you working on a software development project without a heartbeat? Does your project have heartbeat but nobody is listening or monitoring it? It may be time to bring your project to life with a heartbeat that everyone listens to.