Build Frequency
This metric tracks how often the team creates an executable version of the system, integrating the latest developer code.
Main Description

Purpose

Teams build frequently in order to deliver high quality software on schedule. Rather than waiting until the final stages of development to integrate the system components, teams strive to develop, perform unit testing, and integrate early and often (typically several times per day).

By integrating the system more frequently, integration issues are identified earlier, when they are easier to fix, and the overall integration effort is reduced. The result is a higher-quality product and more predictable delivery schedules.

Definition

Count the number of builds per unit of time (per day is standard for teams adopting continuous integration). Calculate the average to monitor over time. 

Analysis

A good way to monitor Build Frequency over time is to use a trend line. Plot the number of builds on the Y axis and time on the X axis. The results can be grouped by build status (passed/ failed).

Expected trend - Builds are frequent (several per day). Integration errors are manageable (because they are discovered early) and overall quality is supported by faster, easier defect identification and diagnosis.

Infrequent builds or inconsistent frequency - When builds are infrequent or inconsistent (less than once per day), integration takes longer, there is a higher risk of integration issues, and bug fixing is more difficult. Developers' code may be out of synch. Rework is typically high. Project schedule may be impacted. Confirm an automated build process is in place and is working efficiently. Encourage developers to integrate their code more frequently, following continuous integration best practices.

In the example below, which shows number of builds passed/failed for the Online Auction project in Smarter Planet, builds are counted per week. Also note in the following chart that the number of builds failed is indicated by the red bar (on top) and the number of builds passed is indicated by the green bar (bottom).

Build Frequency

Frequency and reporting

Build Frequency data is typically tracked daily (or appropriate unit of time based on the team's target build frequency), and reviewed by the team during iteration assessment. Trends are monitored across iterations.

Collection and reporting tools

IBM® Rational® Team Concert® collects build frequency data. IBM® Rational® Insight® reports on this metric.


Assumptions and prerequisites

  • The team has a target build frequency, and conditions specified for when change sets are integrated and a build created.

Pitfalls, advice, and countermeasures

  • Frequent builds improve team morale. Consistently having a working build that grows in functionality helps the team understand their progress and represents the results of their hard work.
  • Frequent builds enforce discipline when teams are facing an aggressive deadline. When developers might take shortcuts in order to deliver more (for example, less unit testing) daily builds will help the team maintain quality.
  • Use this metric with Build Status and Build Health metrics to have a better understanding of the success of builds.