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:
Note: between BuildMaster v5.0 and v6.1, a build was known as a "release package"
Builds may be created via the following methods:
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:
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:
You can use Security and Access Controls to determine which users can perform these actions for which environments.
A build has three possible statuses:
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.
Is this documentation incorrect or incomplete? Help us by contributing!
This documentation is licensed under CC-BY-SA-4.0 and stored in GitHub.