One of the key tenets of Agile development (and probably most development practices these days) is maintenance of an automated build system that allows you to quickly and regularly test and build your various projects. This process is typically referred to as Continous Integration (C.I.). At my current company we’re using Hudson to manage our C.I. strategy, having previously used CruiseControl.

One of the key problems facing any development team is making sure that the build (i.e. the build process managed by your continuous integration tool) remains consistent and stable. There’s no point in developers checking reams of code into source control if the build always breaks with unit test failures or (God forbid) compilation errors!

It’s important therefore that as a team leader/manager you ensure that the builds you and your team are responsible for are broken as infrequently as possible. You can go a long way to ensuring this by educating your team. Emphasise the importance of running tests locally before developers commit their changes to source-control. Show them the value of integration testing and how much easier their professional lives will become once a stable build system is in place.

When we started our most recent stream of system development a year and a half ago, we of-course set up our C.I. build system and scheduled it to run nightly builds of the project. As the project has matured we have found that the number of aspects we want to build and test each evening has widened and consequently the number of different builds running has grown. As time has passed the build has become more and more important. Some of the nightly tasks copy artefacts down to remote sites, a job that cannot be done during the daytime because of bandwidth constraints.

Although my team and I all understand the importance of trying to keep a stable build, we’re also only human. Tight deadlines, unfinished work that needs to be added to source control or just a touch of carelessness can all result in broken builds. On the one hand this is good, the fact that the build is breaking means that we are immediately become aware of problems and can fix them straightaway. On the other hand, it can be hugely frustrating to come in early one morning ready to do some testing with a build artefact, only to find the previous night’s build has failed and you don’t have access to up to date artefacts.

As a team leader I don’t stand great stead in berating my team members and certainly not for something like breaking a build. I also found that as a code contributor on the project, I personally am on occasion guilty of breaking the build myself. I needed a way to encourage not just my team, but also me, to take more care over our code commits and to therefore keep the build stable.

The solution I eventually hit on was simple but effective (and also quite good fun!). Every time a build is broken, the guilty party responsible gets a black mark put against his name on one of our whiteboards. At the end of the month we tally up the blacks marks and the person with the most has to go buy a round of Big Macs for the rest of the team. Although this is a fairly trivial ‘punishment’, it is still enough to make you think twice before committing untested code and for us at least it really has worked. The nice thing about this approach is that it’s quite a passive way of encouraging all team members to take care of the build. Marking the leader board up on a whiteboard also encourages some banter between team colleagues, which really just adds to the fun of the whole process and is in many ways a team bonding tool. Simple, effective and fun, not bad for a technique for encouraging higher quality code and builds!