What is a "Build" in BuildMaster?
  • 01 Feb 2023
  • 8 Minutes to read
  • Dark
  • PDF

What is a "Build" in BuildMaster?

  • Dark
  • PDF

A Build in BuildMaster is primarily used to take code from an application at a certain point in time (a "commit" in Git terms), build/compile it, then deploy it to a series of testing environments before finally making its way to production.

Builds can also be used to:

  • import artifacts from a CI server
  • build and publish packages for developer library packages (NuGet, Python, etc.)
  • deploy Docker container images
  • run scripts for general purpose or control other applications

Because of the wide variety of use cases, builds have a lot of features including pipelines, releases, artifacts, unit tests, reports, variables, notes, etc.

This article will cover the high-level use cases of builds, including:

Git & Source Control Integration

Builds can be tightly integrated with Git services such as GitHub, GitLab, Azure DevOps, and BitBucket. This makes it easy to create a build from any commit in a repository:


This also allows you to quickly compare changes between builds and navigate directly to individual commits or file changes. When you navigate to the Code tab of a build, you'll see all the commits made between that build and the previously deployed build:


See Git & Source Control to learn more.

SVN, TFS, and Other Source Control

BuildMaster also supports other source control providers; see Using SVN, TFS, etc. to learn more.

CI Server (Jenkins, etc.) Integration

Builds can be tightly integrated with CI Servers such as Jenkins or TeamCity, so that you can "import" artifacts from a build on those servers, then later deploy those artifacts with BuildMaster.

For example, after integrating your application with a Jenkins project, a Jenkins tab will become available, and will show recent builds and their status:


Clicking on an individual Jenkins build will display Jenkin's metadata about the build, including parameters and artifacts.


See CI Server (Jenkins, TeamCity, etc.) Integration to learn more.

Creating a Build

There are a several ways a build can be created in BuildMaster:

Creating a Build in the UI

When creating a build of your application in the UI, you may first be prompted to select a build type:


This option will appear if your application has multiple active release, multiple pipelines, or multiple build scripts that could be used.

You may be also prompted to select a Git branch/commit to use when building your code and see variable prompts that were defined in the pipeline.


The Git options will be displayed depending on how you navigated to the create build page. For example, if you navigated to Builds > Create New Build, then you'll be prompted to select a branch. But if you clicked the "green play" button () next to a branch under Git > Branches, then you won't be prompted to select a branch.

Classic UI (BuildMaster 7.0 and earlier)

In BuildMaster 7.0 and earlier, the Create New Build page looks and behaves differently:


The most notable differences are

  • Build number can be set manually; this can be approximated by using a variable prompt and the Set-BuildNumber operation
  • You can opt to not "Automatically advance to «first» stage"; this can be approximated by adding a manual approval to the first stage, or a "dummy stage" that has no deployment targets in the first stage

These options were removed in BuildMaster 2022 because they added complexity and confused users; we also couldn't think of why users would want to do this.

You can access this page in BuildMaster 2022 by clicking "More Options" on the create build page, and then "Use Classic (v7) API". Please let us know if you use this page, as it may be removed in a future version.

Deploying a Build

Similar to creating a build, there are several ways a build can be deployed in BuildMaster:

Deploying a Build in the UI

The build'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 will display a Deploy Build dialog:


Assuming you have the appropriate access controls for the application and environment, you'll be able to do one of the following actions:

  • Deploy Build ; if the build was successfully deployed to the previous stage and meets all approval requirements, you can deploy the build to that stage
  • Override Status; if there was a failure to deploy, you can override the failure to allow a deployment
  • Force Deploy Build; if the build was not successfully deployed to the previous stage (and the status wasn't overridden), or if the build doesn't have the requisite approvals, you can force the build to that stage
  • Re-deploy Build; if the build has already been successfully deployed to that stage, you can redeploy it at any time; this is how you perform a rollback

The deployment of the build can also be scheduled to occur:

  • Immediately when all approval requirements are met
  • Once all approval requirements are met and the specified date and time have passed...

Build Lifecycle, Pipelines, and Releases

Builds are primarily used to build/compile your application's code and then deploy it to a series of testing environments before finally making its way to production. This build-and-deploy process is defined and enforced by the pipeline that's associated with the build. Builds can also be associated with a release.

Pipeline: First Stage

When creating a build with a pipeline, the build will be "deployed" to the first stage of the pipeline. Typically, this stage is Build or Import.

However, if the user doesn't have permission to execute in that environment, or if the first stage requires approvals or deployment windows, the build must be manually moved to the first stage after creation.

Builds and Releases

A release is used to group related builds together, and each of these builds is an attempt to meet the requirements of that release. For example, you may end up to creating twelve different builds of Release 4.2.0 before the code changes are tested, accepted, and deployed to production. Throughout the release, these builds will be in different stages and environments.

Releases are used to help visualize this process. When a build is associated with a release, there are a few behavior changes to keep in mind:

  • Build numbers will be unique to the release; by default, applications use a "Sequential per release" build number scheme, which means that the first build created for a release will be #1, and increment as new builds are created. This makes it easier to keep track of builds within a release.
  • Builds from different releases can share a pipeline stage; by default, pipelines will reject an earlier build if a newer build is deployed to the same environment and that build is in the same release
  • The release's pipeline is used; instead of selecting a pipeline for the build, the pipeline associated with the release will be used

Builds associated with releases will also enable additional features, such as issue tracking synchronization and selecting specific configuration file versions to deploy.

Changing a Build's Release or Pipeline

You can change the release or pipeline that an active build is associated with at anytime.

Changing a build's release or pipeline may yield unintended consequences, such as having build numbers out of order or deployments to stages in a different pipeline/release.

Instead, we recommend creating a new build in desired release or pipeline.

Using Builds without a Pipeline

Starting in BuildMaster 2022, you can create a build that's not associated with a pipeline or release. There are a few cases where this may be helpful.

  • Writing a New Build Script; when you first create an application or want to write a new build script, this kind of build may be convenient to use to test out your script
  • CI-only Builds; you may want to automatically create builds from certain branches that will never be deployed, or that you will add to a deployment pipeline later

When creating a build without a pipeline, all other pipeline-less builds will be rejected.

You can also deploy a build that's not associated with a pipeline, but the options will be much more limited than what's available in a deployment pipeline. You can only select a single script, and a single server to run that script on. This mostly useful for writing new deployment scripts.

Build Status

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; instead, determined to be inadequate or otherwise inappropriate for the final stage

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

Users can manually reject builds, and depending on how the pipeline is configured, builds can be automatically rejected when another build enters the same stage. Administrators can also change the build status at any time. However, this should only be done in exceptional situations, for example, to "un-reject" a build that was accidentally rejected or to correct other errors.

Was this article helpful?