A release in BuildMaster can be thought of as an event. It represents the changes that are being made to an application; anything from a major product launch down to a single-line-change rushed to production in an emergency. BuildMaster makes release automation and deploying software easy and secure, and provides a central dashboard for all your applications.
Release Packages create certainty that what gets deployed to production is what has been tested through various environments. A Release Package is what is actually advancing through the pipeline into production. It can’t be changed or replaced; it must be either accepted and deployed, or rejected in its entirety.
Release package artifacts can enter a pipeline through a variety of ways:
A Release is composed of many different components not only release packages. Some releases may be more complex than others; with BuildMaster you are able to create a release that consists of any or all of the following: issues and notes, changes to configurations files, database changes, variables, or manual/automated approvals. The combination of these things allows users to coordinate stages of the release lifecycle from creating or importing an artifact all the way through to production.
The various components of a release facilitate how you meet organizational requirements, and allow you to structure simple or trivial changes and major, complex releases.
Release packages are deployed through the different stages of a pipeline. A deployment of a release package indicates that it has been successfully vetted and tested in accordance with the requirements of the specific stage in the pipeline (ie. Gate, environment, deployment plan, etc.)
A release package may also be rejected in its entirety. If the deployment plan is not successfully executed or any artifact in the release package is deemed unsuitable, the package is rejected and a new package may be created.
Release templates add another level of flexibility in BuildMaster. You are now able to create a release from a template, giving you the ability the make sure the appropriate deployables are added for that release. For example if there are multiple supported version of an application, you may have a patch release template for the older version that will have different deployables compared to a major feature release for the most current version. Taking the guess work out of the process, overall reducing human error, and saving time.
With each release template you are able to define the appropriate deployables, Pipeline, and are even able to edit in either visual or code view, which ever you prefer.