BuildMaster Documentation

Releases in BuildMaster

  • Last Modified: 2019-08-27

A release is an event where a planned set of changes are tested and delivered to production, or more specifically, a final pipeline stage. Releases can vary in conceptual size, from a major product launch, to a single-line change rushed to production in an emergency. The deployment unit that is promoted through a pipeline in order to effectively deploy a release is referred to as a build.

In addition to the application code you want to deploy, releases have several associated features available to automate and coordinate the software release process:

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

Creating Releases

After creating an application and a pipeline, a release may be created for an application. A release has the following initial properties:

  • Release template - if one exists, a release template may be selected to determine variable prompts, default pipeline, and more
  • 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 builds 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.

Status and Lifecycles

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

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

Target Dates

Release target dates can be configured to specify a milestone or window of time during a release along with a description. These dates can be added to a calendar view for high-level visibility. Common examples include:

  • indicating the future release date
  • expected range of dates when UAT can expect a build that they can test
  • estimated date(s) when a pre-release version is shipped

Is this documentation incorrect or incomplete? Help us by contributing!

This documentation is licensed under CC-BY-SA-4.0 and stored in GitHub.

Generated from commit 7dbbedf1 on master