Continuous Deployment - Continuous Integration - page 195

removed and reapplied will depend on the desired level of risk. If a
software application relies on various operating system files, then it
may be wise to clean the entire system more often. In any case, we rec-
ommend that all layers be removed at least a few times before releas-
ing the software to end users.
Label Each Build
Creating a unique identifier for a build, build labels, follows two
steps: First, the code in the repository requires a label (as just dis-
cussed); second, the actual act of building that code requires a unique
label. These build labels create a common understanding of what ver-
sion of code is in a particular environment; moreover, through build
labeling, defects, features, and new requirements can be issued against
that instance of a code base.
Note the difference, however, between a repository label and a
build label. Repository labels signify that a group of files (usually
uncompiled ones) are related. Build labels signify a binary output of a
build as being unique. This could be a series of executables, a .jar file,
a .NET assembly, or even a .zip file. The two naming schemes, how-
ever, are usually related, with build labels being slightly more specific
in terms of build number and platform. Be sure that everyone knows
and follows the conventions for your development project. For
instance, if the repository label is 2_89 , a build of that snapshot of
code could be 2_89.01 . If the build is targeting a specific platform,
then additional information can be affixed, such as 2_89.hp-01 .
Not labeling a build makes it difficult to associate features, defects,
or requirements to a binary artifact. For example, deploying an unla-
beled build to a testing environment, such as QA, in essence creates a
moving target. If the QA team finds a defect, then coordinating with
the development team can be problematic. Without the ability to pin-
point when the problem occurred, it becomes difficult to identify what
led up to the issue. If builds are labeled, however, problem reporting
becomes a matter of specifying a build's unique identification.