Code Leader: Using People, Tools, and Processes to Build Successful Software

3.3. Fix a Broken Build before Integrating Changes

For Continuous Integration to work, it must be the primary goal of every developer to make sure that the build doesn't break. Seriously. Not breaking the build becomes the most important job of everyone on the project, all the time.

The whole point of CI is to reduce the integration work required for a project, and more important, the risk associated with that integration work. By keeping each integration as small as possible, and by completing those integrations early and often, the overall risk of any given integration cycle hurting the project schedule is vastly reduced. It also makes each integration cycle much easier for the developers involved. If the build is broken, then that cycle of integrations cannot proceed until the build is fixed. If the team can't count on the integrity of the source code at the "head" of the version control tree, then they cannot integrate with it. That means integrations they would otherwise be accomplishing smoothly get put on hold, and this costs the team time and money. If the team is serious about CI, then a broken build brings the entire team to a halt until that build is fixed.

This can be very difficult to communicate to a team that is just getting started with CI. It is one of the hardest behaviors to instill in a team, even one seasoned in Continuous Integration process. If developers don't take a broken build seriously enough, they will hold up the team or compound the problem by continuing ...