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).

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.
|