A Build represents an attempt at implementing the requirements of a
particular release. It also serves
as a snapshot of an Application's codebase that is promoted and tested
throughout the application's environments.
For nearly all releases of an application, there will be several (if not
many) builds created. Each build follows a similar process:
- The code is compiled, built or otherwise assembled into a "build" and then
deployed into a non-production application environment such as "Integration."
- The Build is tested in that environment and, if it meets the necessary
testing criteria, is promoted to another non-production environment.
- The process continues until the build is determined to be either
inadequate (and then rejected) or until it reaches the final, production
When a build is created, it begins in an Active status. As an Active Build,
two things can happen:
- It is promoted to an environment (eg Development, Test, QA, Production) as
defined by the Release's workflow.
- It becomes Rejected, in which case the build can no longer be promoted or
used in any meaningful manner.
When a build is promoted to the final (ie Production) environment, it becomes
Like Releases, Builds have a key attributed called Build Number. The Build
Number serves two purposes:
- Uniquely identifies a build within a release
- Determines the sequence of one build relative to another
There are several different ways in which a build number can be formatted.
BuildMaster supports the most commonly used:
- Sequential – Build Numbers within a release start at 1 and
increment when a new build is created.
- Date – Build Numbers consist of a year, month, day, and
sequence-in-day. The first build on May 5th, 2009 would be 20090505001, the
second 20090505002, and so on.
We recommended Sequential build numbers as it's much easier to discuss "Build
6" than "Build 20090507003." However, the disadvantage of sequential numbers is
that they must be used in the context of a release: 3.2 Build 7, 3.4 Build 6,
etc. While length, date-based build numbers provide an absolute context (i.e.
the date created).
Note that, like the release numbering scheme, the build numbering scheme may
only be selected when the application is first created.
Unlike Releases, a greater build number within a release does not imply that
a build supersedes an earlier build. For example, Build 7 could be mostly
bug-free, while Build 8 (a build in an earlier environment such as Integration) introduces a show-stopping bug.
In this case, Build 7 would be more suitable and could be deployed instead of Build 8, thus Build 7 becomes
deployed for the release while Build 8 is rejected.
In and of itself, a Build is little more than a Build Number. It is only when
a build is promoted to an environment (such as Dev) that it has any meaning.
A Build Promotion is simply an indication that a build has been approved for
a certain environment such as Dev, Test, QA, or Production. In almost all
scenarios, when a build is created, it is automatically promoted to the first
(usually "Dev") environment.
A build may be promoted to a further environment under the following
- The build has been successfully promoted to the previous environment.
- All approvals required for that promotion have been met.
- Any other promotion requirements (such as having all issues resolved) are
- A build promotion is forced to its next environment even if some approvals or promotion requirements are missing.
A promotion is considered to be successful when:
- An execution (ie running of a deployment plan) has been successful.
- A user manually indicated that the promotion was successful.
There are three scenarios in which a build can be rejected.
- Through the course of testing, a developer or tester determines that the
build is unsuitable and (provided he or she has permission to) rejects the
- If an active build has been promoted to an environment in which another
build within the same release has been promoted to (but not promoted beyond),
it will supersede and reject the other build. For example, if Build 7 has been
promoted to QA (but no further) and Build 8 is then promoted to QA, it will
supersede and then change the status of Build 7 to Rejected.
- When a Release is canceled, all Active builds are rejected.
Note that a Rejection is not the opposite of an approval – once a
build has been rejected, it can no longer be used in any meaningful manner.
A Build Artifact is a "snapshot" of files that were used or created at some point in the build process.
Under the hood, artifacts are simply stored as zip files.
BuildMaster allows you to create any number of artifacts at any point in the deployment process, and it
stores and manages those artifacts by associating them with the build.
The artifacts can be used for building or deploying later on, or simply kept for archival purposes.
The most common use of artifacts is to save the output of a build. It is recommended that artifacts of build output are
created early on in the workflow so that they may be simply deployed in later environments. Using the same
artifact throughout multiple enviroments also maintains the concept of build immutability.
Besides build output, artifacts may be used to store any of the following:
- A collection of database scripts
- NuGet packages
- Help files and documentation
- Release notes
Automatic Builds & Continuous Integration
Following the concept of Continuous Integration, the practice of integrating a developer's code changes into the software's source control management system should occur frequently enough such that there is very little time between a commit and a build. This practice helps to identify errors in a build and allows them to be quickly corrected.
BuildMaster offers 3 types of automatic builds that can be used for your own Continuous Integration process:
A Workflow may be configured to require approvals before a build may be
promoted to a certain environment. In this case, the appropriate users must
indicate that the appropriate approvals have been met.
All required approvals will be on indicated on the build page prior to that
build's promotion. For example, if a smoke test must be performed prior to going
to test, and regression tests must pass prior to going to QA:
- When the build has been promoted to dev, the "Smoke Tests Passed"
requirement will be visible.
- When the build has promoted to test, the "Regression Test" requirement
will be visible.
In the event that approvals have not been received, but the build must be
promoted regardless, the promotion may be forced. Obviously, forcing a promotion
should only be used in exceptional circumstances, otherwise all sense of
process/best practice breaks down.
This content has the following tags: