Photo by Alfred T. Palmer. Library of Congress, Prints & Photographs Division, FSA-OWI Collection, Reproduction Number: LC-USW361-138.

Making wiring assemblies at a junction box on the fire wall for the right engine of a B-25 bomber, North American Aviation, Inc. Inglewood, California, July 1942.

All developers work in their own Private Workspace (6) so that they can control when they see other changes. This helps individual developers make progress, but in many workspaces people are making independent changes that must integrate together, and the whole system must build reliably. This pattern addresses mechanisms for helping ensure that the code for a system always builds.

Note

How do you make sure that the code base always builds reliably?

Because many people are making changes, it isn't possible for a lone developer to be 100 percent sure that the entire system will build after the changes are integrated into the mainline. Someone can be making a change in parallel with you that is incompatible with your change. Communication can help you avoid these situations, but problems still happen.

When you check in code changes, you may, despite your best intentions, introduce build errors. You may not need to build the entire code base before a check-in; there may be components that you don't know about or that are not part of another team's work. Your build environment may be inconsistent with the “release” build environment at any point. For example, if you work on a PC or a workstation, you may be slightly out of date with respect to the standard, in terms of compiler or operating system version or version for a third-party component. Or you may be trying out a new version of a component that seems compatible with the version everyone else is using. Duplicating your effort on multiple systems when the risks of a problem are small seems wasteful.

The best you can do is to try to build everything. A complete, clean build may take more time than you, or any other developer, can afford to spend. On the other hand, the time it takes for one person to do a complete build may be small compared with the time the team takes to resolve the problem; if you break the build, it will slow other people down. It is better to localize the problem as soon as you can. As Figure 9-1 shows, integration can be tricky, akin to putting puzzle pieces together.

Figure 9-1. Integration can be difficult.

A complete, centralized build may address some of these problems, but a centralized build works from checked-in code, so the damage is already done.

Some users of the system may not want, need, or be able to build the entire code base. If they are developing software that simply builds on top of another component, worrying about integration build issues will be a waste of their energy. They want a snapshot of the system that they know builds.

Tracking down inconsistent change sets is frustrating work for other developers, so the smoother the build, the higher the morale. You need a way to ensure that these inconsistencies are caught as quickly as possible, in an automated, centralized manner.

Do a Centralized Build

Note

Be sure that all changes (and their dependencies) are built using a central integration build process.

This build process should be

• Reproducible.

• As close as possible to the final product build. Minor items, such as how files are version labeled might vary, but it is best if the integration build is the same as the product build. At the end of the integration build, you should have a candidate for testing.

• Automated or requiring minimal intervention to work. The harder a build is to run, the more even the best-intentioned teams will occasionally skip the process. If your source control system supports triggers, you could run the build on every check-in.

• A notification or logging mechanism to identify errors and inconsistencies. The sooner build errors are identified, the sooner they can be fixed. Also, rapid notification makes it easier to track the change that broke the build.

Having a centralized process simplifies integration, as Figure 9-2 shows.

Figure 9-2. An Integration Build Process Assembles the Pieces.

Perform the build in a workspace that contains the components being integrated. Determine how often to run the integration build based on the following factors:

• How long it takes to build the system

• How quickly changes are happening

If the system takes a long time to build or if the product is fairly static, consider at least a staged daily build, with an option to run additional builds as needed.

If the system can be built fairly quickly, consider running the build on every submission (check-in) to source control. Although this may seem resource intensive, it makes it very easy to determine the sequence of changes that broke the build. The trade-off is that if your version control system does not serialize changes adequately, you may have build failures simply because of inconsistencies.

Identify this build with a label in your version control system.

The integration build should be repeated on all supported platforms when the system supports them. Having individual developers do multiple builds can be a time sink.

Remember, the intent of the integration build is to catch build issues that fall through the cracks. Only if the builds fail consistently for the same reason should you add precheck-in verification steps.

If appropriate, use the integration build as the basis for an installation kit.

You check in a change to the repository. The source control system responds to the check-in by extracting all the files for the system, and it builds the resulting system. Errors in the build are reported to the build master as well as the person who submitted the change.