A build in BuildMaster is the fundamental unit of deployment under the context of a release that advances through a sequence of pipeline stages in order to effectively deploy a release. Its components may consist of any or all of the following:

• Artifacts
• Unit Tests
• Reports
• Variables
• Notes

Creating a Build

Builds may be created via the following methods:

• "Create Build" button in the UI
• Release & Build API
• Automatically via Continuous Integration

In order a create a build, at least one release must exist for an application. When creating a build from UI, there are at minimum three initial options:

• Release – the release that the build is associated with; this will inherit the pipeline and prompt for the appropriate release template variables upon creation
• Build number - this is an integer that uniquely identifies a build within a release, the default value will sequentially follow the current latest build's number
• Automatically advance to first stage - when checked, the build will be automatically deployed to its first stage of the release pipeline; this is a common workflow in BuildMaster, as the first stage typically adds artifacts to the build. However, if there are deployment variables required, approvals, or deployment windows for the first stage, advancement must occur after the build is created

Deploying a Build

The release's pipeline determines where the build will be deployed, as well as what approvals are required before deploying to each stage.

Clicking on one of the stages in the build's pipeline status will present one of the following dialogs:

• Deploy Build - if a build was successfully deployed to the previous stage and meets all approval requirements, you can deploy the build to that stage
• Force Build - if a build was not successfully deployed to the previous stage, or if it doesn't have the requisite approvals, you can force the build to that stage
• Re-deploy Build - if a build has already been successfully deployed to that stage, you can redeploy it at any time; this is how you perform a rollback of a build

You can use Security and Access Controls to determine which users can perform these actions for which environments.

Status and Lifecycles

A build has three possible statuses:

• Active - progressing through its pipeline with the possibility of being deployed to the final stage
• Deployed - successfully deployed to the final stage of its pipeline
• Rejected - not deployed to its final stage, and instead determined to be inadequate or otherwise inappropriate for the final stage

When a build is successfully deployed to the final stage of its pipeline, both the release and build status is automatically changed to Deployed. This is controlled by the pipeline, and can be configured to behave differently.

Users may manually reject builds and, depending on pipeline configuration, builds may automatically be rejected if another build enters the same stage. Administrators may also change build status at any time, however, this should only be done in exceptional situations such as to "unreject" an accidentally-rejected build or correct other mistakes.