Builds

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:

  1. The code is compiled, built or otherwise assembled into a "build" and then deployed into a non-production application environment such as "Integration."
  2. The Build is tested in that environment and, if it meets the necessary testing criteria, is promoted to another non-production environment.
  3. The process continues until the build is determined to be either inadequate (and then rejected) or until it reaches the final, production environment.

Build Lifecycle

When a build is created, it begins in an Active status. As an Active Build, two things can happen:

  1. It is promoted to an environment (eg Development, Test, QA, Production) as defined by the Release's workflow.
  2. 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 Deployed.

Build Lifecycle

Build Numbering

Like Releases, Builds have a key attributed called Build Number. The Build Number serves two purposes:

There are several different ways in which a build number can be formatted. BuildMaster supports the most commonly used:

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.

Ordering

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.

Promoting

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 conditions:

A promotion is considered to be successful when:

Rejecting

There are three scenarios in which a build can be rejected.

  1. 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 build.
  2. 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.
  3. 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.

Build Artifacts

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:

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:

Approvals

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:

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.

More on this topic:

This content has the following tags:

buildmasterreleases