18.2 Frequent-Build Technique

18.2 Frequent-Build Technique

The frequent-build technique, also known as build-and-smoke-test, daily builds, continuous integration, or personal builds, is an integrated part of agile and iterative development. It may also be used for sequential development during coding and integration. The purpose of frequent-build is to build and test the entire system or the available part of the system often, possibly daily. This is to say that all source files are compiled and linked to build an executable system. Some sort of test is then performed to see if the product works. This test may vary from superficial to thorough, according to the needs and possibilities.

Planning Considerations

It's a planning decision to include frequent-build in development activities. Successful use of this technique depends on cooperation between the involved roles: development, integration, test, quality assurance, and configuration management. Frequent-build includes the following steps:

• Establish a build group . This must be done in cooperation with configuration management.

• Build as often as meaningfulas often as new changes may be synchronized.

• Test every build. Make it a first priority to make sure every build works, or fall back.

• Introduce reprisals if a build doesn't workbut don't make it buying a cake if you want to stay slim.

As with other techniques, frequent-build should be performed even under pressure. People make more mistakes under pressure, and it's in these situations that the technique may prove its worth.

Configuration Management Considerations

Frequent-build poses special requirements for configuration management. However, these requirements are not difficult to fulfill, and most tools support them. When items are placed under configuration management oftenwhen change cycles are as short as one day or the time it takes to make a useful changethe configuration management system must be able to handle a large storage volume. For the sake of development speed, consider also how registrations and subsequent extraction of metadata may be performed as quickly and smoothly as possible and, perhaps most important, how fast builds can be made. It may be a good idea to invest in a good, sturdy, fast database tool.

Frequent Builds Are Not Frequent Storage

The frequent-build technique should not be confused with the frequent placement of items in storage. Only finished and approved configuration itemsitems that provide a tested solution for a specific taskmay be placed under configuration management. Intermediate "solutions" are private!

Identification

Builds must be identified as precisely as possible. This is often done by adding a running build number to the identification: System XZ, version 2.03.743, where 743 is the build number. It may also be in the form of a date: System ZY, version 3.5-01.04.11, where 01.04.11 indicates that this version was built on April 11, 2001. Configuration items that are part of the build are "ordinary" items and should be identified according to their type.

Building

Building a system is a type of release for use. The test is the use, and its purpose is to ensure internal consistency. It has to be easy to establish a new version of the product, composed of the latest version of all relevant configuration items. It's a great advantage if this work can be done fast, such as by performing an optimized build.

A good build procedure is necessary. It's a good idea to produce a generic build script, which automatically includes the latest version of the relevant configuration items. Furthermore, the script must produce a list of the contents with full identification, so it's possible to see which versions of the configuration items are included in a given build.

Frequent-build depends on the test. The test specification needs to be changed as frequently as the build, especially if the test is to touch all parts of the product in a convincing way. It's therefore advantageous to place test scripts and so on under configuration management with the rest of the configuration items in the build.

Storage

Placing the version of the system being built under configuration management can be done by placing its build script under configuration management as a proxy item for the system. This will save space and in most cases it will be easier to handle the build script than if the executables were placed under configuration management. In this way, it's possible to rebuild a version of the system if this should prove necessary (provided that the individual items are available).

Backtracking

Frequent-build ensures the quality of what is being developed and placed under configuration management, and it should be an exception for a developer to ruin a build. Microsoft is infamous for equipping its developers with a pager, to call them to work even in the middle of the night if they've caused a build to fail. Builds do fail, and if a major problem is introduced, it may be necessary to fall back to the previous version.

Change Control

As mentioned above, it should be an exception for a build not to pass the test, and it should be taken seriously if it doesn't. The event(s) connected with the failure must be registered, treated like other events, and given highest priority. For frequent-build to fulfill its purpose of ensuring the earliest identification and correction of errors, it's important to follow build test events closely and get them out of way before a new build is done.

Example

The following example has kindly been provided by Mr. Bjarne Mnsson from Baan CRM in Denmark. During development of a new product, Baan CRM used the frequent-build technique, as described below. All source code was version-controlled in Microsoft Visual SourceSafe (VSS)source code was checked into VSS daily. Source code of a full build was labeled with a unique label, so a particular version could always be rebuilt. Development and build environments were saved as an "image" of the PCsthat is, there was no saving of individual development tools. All components were integrated into a full system on a daily basis, including an automatic regression test.

Initially, a problem was identified: that source code was checked into VSS on a daily basisthat is, the "morning" build was performed on the latest (but maybe not tested) code. Figure 18-1 shows the results of the daily builds of the product's seven components. The points above the x -axis indicate failed builds, so Figure 18-1 shows that of the 87 builds from August 14 to December 12, 68 have points lying above the x -axis. Only 19 don't have points above the x -axis and were therefore entirely successful.

Figure 18-1. Initial Build Success, All Subsystems

The beta release was on December 4, 2000; only around this time could improvement be spotted. This prompted a new approach: building on "promoted" code only, which was tested against other components before promotion, as illustrated in Figure 18-2.

Figure 18-2. Promotion of Code

The advantages of this were that the developer promoted the code only when it was stable, it was tested against other promoted code, and the code for the build was stable. The disadvantages were that the build code might be a week old, and the promotion process needed tuning. However, this approach did provide much more stable builds, as illustrated in Figures 18-3 and Figure 18-4.

Figure 18-3. Configurator Subsystem Beta Release August 24, 2001: 75% Successful

Figure 18-4. Salespoint Subsystem Beta Release August 17, 2001: 95% Successful