Preflight Builds

With these practices in place, most teams will find broken builds to be minor nuisance; and yet, they will persist. If developers are doing builds and tests prior to commit, one might wonder why this should be the case. Some teams may consider using preflight builds — builds that use the developer's source but build on the authoritative environment or with the official build process. Preflight builds are also known as pre-commit builds, and pre-tested builds.

Some approaches might even attempt to automatically revert any changes to source control or intercept commits. But does checking builds before a commit reduce the breakage rate to zero? Before going too far down this road, let us look at the causes of broken builds.

Causes of Broken Builds

Some broken builds will be caused by sloppiness — simply committing only a subset of the source changes a developer made. Automatic reverting would work here, but repairing the build is so trivial that it doesn't provide much. More commonly, an interface change will be at the heart of the problem. A dependency may change its interface and become selected for use by a dependency management system like Codestation or Apache's Maven. When this occurs, the next build may fail, but the new commit will not be to blame, and the automated cleverness starts causing more harm than good.

Similarly, developers may intentionally change an interface or pattern in the application, to intentionally break the build. Several developers can then share in the task of updating various objects to the new model. Again, a system that aims at reducing the pain of broken builds by intercepting commits will just get in the way.

From time to time, two developers will commit at about the same time and their changes will be incompatible. While an automated system could arbitrarily kick one set of changes out, if the team is trustworthy, it's usually better to just notify them that the combined changes broke the build and give the two developers responsibility for reconciliation. Integration failures of this type is exactly what a Continuous Integration server is designed to catch.

Commit Interception Is Too Much Trouble

Preflight builds that block commit of failed changes, or that automatically revert changes going into a newly broken build, can cause more trouble than their worth. However, that doesn't rule out all preflight builds. Some broken builds happen even if developers are doing everything right, and there are no collisions. Sometimes the failure can be caused by environmental differences between the developers' machines and the authoritative build environment. If this happens frequently, resolving the environmental differences may be the best fix. If that is impossible, preflight builds on the authoritative build server may be a helpful tool while the team addresses that piece of build fragility.

Preflight builds can be put in place using a number of techniques. For source control tools that have individual developer streams, configurations can be put in place to build off arbitrary streams. Developers can then kick off these builds and check the results before promoting their code. Otherwise, the build server will need to provide facilities for retrieving the source code from the developer's machine, which is the first step of a preflight build. Used responsibly, preflight builds support the first pillar of pain free building by reducing the number of build failures.