Build Before Commit

The most obvious tactic to reduce build failures is that the developers should update their workspaces and build the software on their own machine before any commit. Ideally, they will also run an appropriate set of fast unit tests as well. Doing this should catch the vast majority of problems and considerably reduce the number of broken builds. This supports the first pillar of pain free building. This technique is most effective when the developers' build process and environment closely mirror that of the official build environment. Developers should build their software using the same build scripts that are run in the authoritative environment.

The likelihood of developers consistently building before the commit is inversely proportional to the speed of the build. Again, fast builds are key here. If a build takes just a few seconds to go through and validate, developers will consistently run it before commits. As the build starts to take a long time, and blocks developers from doing more work, they will tend to commit less frequently while skipping the local build.

Developer builds show the relationship between the first pillar of pain free building (infrequent build breakages) and the second (fast builds).