Having an automated, fast, repeatable build provides the heartbeat of the project. Sadly it's often neglected and viewed as tedious to set up, boring to maintain and the only time it actually does get any attention is when it doens't work. Good build systems exhibit a few key charecteristics, today Im going to talk about one of the finer points, stability.
What is stability?
The stability of a build can be stated as:
Unless something changed, do nothing.
Or as
Ant best practices item "14. Perform the Clean Build Test" puts it:
Assuming your buildfile has clean and compile targets, perform the following test. First, type ant clean. Second, type ant compile. Third, type ant compile again. The third step should do absolutely nothing. If files compile a second time, something is wrong with your buildfile.
Why stability?
Stability is important since it has a direct effect on the length of your build/test cycle. Any inefficency introduced grows both with the project and with the number of team members. This means that unless you keep your build stable every compile will cost you a small amount of time, for every team member, over time this adds up to substantial amount.
Easy ways to fail.
There's a few ways that almost every build system I've worked with failed the stability test the most common offenders I've found are.
Unconditional Post Build xcopy
It's often convinent and sometimes neccessary to copy output files to some other directory. Often this is done to create smaller solutions/projectfiles for the IDE and more stable projects are simply built and copied to a folder with precompiled binaries and referenced from there. This is a good strategy. The problem arise when the copy is unconditional since this often forces a rebuild of all dependent projects even though the shared library did not change! If you're using Visual Studio, unless you got a really really good reason always use "When the build updates the project output" option for "Run the post-build event:". If you're using Ant/NAnt/Rake/
and have a target that does compile+copy always check before copying.
Unguarded build targets
Common offenders in this category is test/coverage targets, creation of installation packages and "zip tasks", care should always be taken to ensure that something actually did change before redoing theese procedures. Often this can be accomplished by comparing timestamps for the source and destination files. If no tangible output is generated by default it can make sense to introduce a marker file and touche it on completion of the task.
Summary
Keep your build fast by avoiding redundant work, take care to never do work unless something actually did change.
