Building For Success

all of which engender trust in the result. As we discussed last month, manual build processes tend not to have these properties – all it takes is a loss of concentration at a crucial moment, or something dodgy in the environment, and the build produced is not reliable.

Thus we would always recommend a “one button build” – an automatic way of doing the whole thing by executing a single command.

This is nice and simple in some environments, particularly where a clean build from scratch takes a small amount of time, e.g. in the order of minutes.

As soon as builds start taking tens of minutes or hours, they can have a potentially large negative impact on the velocity of the team. People start to find work arounds to avoid being held up, and if not given good guidance and help they cause problems. One of the fundamental practices of agile development (and SCM) is that fast and frequent feedback gives major benefits. Problems swept under the carpet that surface later can be exponentially more difficult to deal with at that time.

So what other factors affect build velocity and what can we do to improve it?

• Fast machines!
• Shared build servers

• Incremental builds and different build tools

• IDEs

• Share library problems

Fast Machines/Build Servers

It is amazing how much difference a fast machine can make to a build. By their nature, builds are compute intensive tasks (though can also be I/O intensive for things like dependency checking) and a PC suitable for standard office work will have developers twiddling thumbs and drowning in coffee.

Like any system, decisions to not provide fast machines are very seldom taken “with malice aforethought” to purposely make developer’s lives difficult. It is usually lack of knowledge and not looking at the whole process, leading to unintentional side effects.

The trend for outsourcing is often a source of problems. What used to be a simple request to upgrade a machine or similar and could be solved by someone from the IT department coming round in an hour or two, may require raising a request to some remote support centre and some huge rigmarole of a process which requires incantations and the blood of your first born! A recent experience of one of the authors was where the need to delete some corrupted files from a proxy server, the work of a few minutes, was estimated to take 2 weeks to wend its merry way through the system. Meanwhile, 20 developers had to work around the problem!

At the very least, a shared (and fast!) build server which can turn around builds quickly can be a great boon. This concept of course can be extended to include build farms for parallel builds – for which various commercial and open source solutions exist – well worth investigating. In itself a potentially deep topic which we will look at in the future (or maybe covered elsewhere in CMCrossroads).

Incremental Builds 
As mentioned above, the gold standard build is a clean build from scratch. For complete system builds, it is always going to be the preferred solution.

However, if you have just changed a few modules since the last build and recompiling/linking would take a minute or two instead of the 30 minutes for the whole thing, the incremental build is always going to look very attractive. If done well, it is an excellent tool to have in your team’s repertoire.

The key to is having accurate dependency checking in your build system.

The art of writing build scripts and using tools to automate this is something