Information Technology Reference
In-Depth Information
Ten-Minute Builds
In
Extreme Programming Explained
, Second Edition, Kent Beck
suggests that a good rule of thumb is to keep your (integration)
builds to no more than ten minutes. Many developers who use CI
follow the practice of not moving on to the next task until their most
recent checkin integrates successfully. Therefore, builds taking
longer than ten minutes can interrupt their flow. This suggestion
can work for most projects. Your ten-minute commit build doesn't
need to run every type of test or inspection. You can offload the
time it takes to run a build by running multiple build types in suc-
cession (as mentioned earlier, what Fowler calls “staged builds”).
Gather Build Metrics
The first step in improving a build's duration is to capture build met-
rics. Table 4-2 lists some common metrics that can produce a more
qualitative analysis of your integration build process. You probably
won't need to gather all of these build metrics every time, but it is a
useful exercise if you are unsure about a problem or would rather not
waste time attempting to fix problems that don't exist.
Integration Build Metrics
TABLE 4-2
Integration Build Metric
Description
Compilation time
The time it takes to compile the software, and how it
compares to your past compile times.
Number of source lines of code
(SLOC)
This indicates the system's size or at least what needs to
be compiled.
Number and types of
inspections
The number of different types of inspections you are
performing. Consider eliminating any redundancy.
Average assembly generation
time
The time it takes to generate the assembly, archive, or
however you are packaging the software.
Test execution time (based on
category)
The time it takes to perform testing at each level: unit,
component, and system (these are described in Chapter 6).
