BuildMaster Documentation

Releases in BuildMaster

A release is an event where a planned set of changes are tested and delivered to production (or another final stage) using a release package. Releases can be anything from a major product launch to a single-line change, that's rushed to production in an emergency.

Release packages use artifacts to store and deploy your application components. You can add artifacts to a release package with a variety of different methods:

  • Upload a zip file to the web interface
  • Capture from a drop path on a network share
  • Compile from source code within BuildMaster
  • Import from a CI server like Jenkins or TeamCity

In addition to the application code you want to deploy, releases have several components that you can use to automate and coordinate your software release process:

  • Dates and milestones
  • Issues and changes
  • Configuration file changes
  • Database change scripts
  • Manual change controls
  • Release notes

You don't need to use any of these features at first, but you many find them helpful as you build a more robust release management platform.

Creating and Deploying Releases

After creating an application and a pipeline, you can create a new release of an application. A release has the following initial properties:

  • Release number is a one-to-three part number (e.g. 88, 2.4, or 4.1.8) that uniquely identifies a release within an application
  • Release name is an optional alias you can use to create a friendlier release identifier; it is not unique within an application
  • Pipeline is the sequence of stages and approvals that release package are promoted through

Once a release is created, you can add configuration variables that can be used by deployment plans at runtime, target dates that will be show on a calendar, and so on.

Release Packages

Once a release has been created, you can create a release package for that release. There are two initial options:

  • Package number; this is an integer that uniquely identifies a release package with in a release, and generally is sequential
  • Automatically deploy; when checked, the release package will be automatically deployed to its first stage of the release pipeline; this is a typical workflow in BuildMaster, as the first stage typically adds artifacts to the release package

You can also add configuration variables to release packages that will be used by deployment plans at runtime.

Deploying Packages

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

Deploying packages

Clicking on a particular stage for a release package's pipeline status will open up one of the following dialogs:

  • Deploy Package; if a package was successfully deployed to the previous stage and meets all approval requirements, you can deploy the package to that stage
  • Force Package; if a package was not successfully deployed to the previous stage, or if it doesn't have the requisite approvals, you can force the package to that stage
  • Re-deploy Package; if a package has already been successfully deployed to that stage, you can redeploy it at anytime

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

Scheduling Deployments

There are two options for scheduling a the deployment of a release package:

  • Scheduled Promotion; the package will automatically be deployed at the give time, provided all approvals are met at that time
  • Scheduled Deployment; the package has already been approved, and will be deployed at the specified time

The option to perform a scheduled promotion will only be present if the package would otherwise have to be forced into the next environment.

Release Templates

Coming soon!

Status and Lifecycles

A release can be in one of three statuses that reflect the state of development:

  • Active: release packages are being created and deployed through pipelines
  • Deployed: a release package was deployed to the final stage of its pipeline
  • Canceled: no release package was deployed to the final stage, and release packages are no longer being created or deployed; all release packages are also rejected

A release package also has three similar 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 release package is successfully deployed to the final stage of its pipeline, both the release and release package status is automatically changed to Deployed. This is controlled by the pipeline, and can be configured to behave differently.

Users may reject release packages and, depending on pipeline configuration, release packages may automatically be rejected if another package enters the same stage.

Administrators may also change the status at any time. This should only be done in exceptional situations, such as to "unreject" a deployment set, or correct other mistakes.