Change Management: Release Management Process

The Release process provides a mechanism for managing the building, testing, and release of a set of changes.

There are three main sections to this process:

The first stage of the process enables you to define the release, including adding Child Changes to the release.	The release is then built and tested.	Following successful testing, the release is rolled out to the organisation.

Defining the release

When you first log a new Release, you provide an outline and description of the release, the proposed release date, and can attach any existing Release Plan Documentation.At the bottom of the window there are two tabs, which display the results of the queries Releases Planned For This Day, and Release Tests still Outstanding. For more information about these queries, see Queries.

The Release Details window contains two list boxes that enable you to specify the form and type of the release. These list boxes are populated with values from reference lists. For more information about these reference lists, see Reference lists.

Use...	to specify whether the release is...
Form of Release	Major (containing large areas of new functionality; a Major Release usually supersedes all preceding Minor and Emergency Releases); Minor (containing small enhancements and fixes; a Minor Release usually supersedes all preceding Emergency Releases); Emergency (containing fixes to a small number of Problems).
Release Type	Full (all of the components of the release are built, tested, distributed and implemented together); Delta (only those CIs that have actually changed since the previous release are included); Package (multiple Releases that are to be rolled out together).

When you have saved the release, you can add the necessary Changes to it using the Add Child Change action. Child Changes that you add to the release in this way appear in the Change Tree as Children.

Building and testing the release

When you have added the required Changes to the Release, you build, configure, and then test the Release.

The Build and Configure Release action enables you to add a description of the build and configuration. When the build is complete, Build Failed and Build Successful actions become available.

If the build fails, you can either close the release, or build and configure the release again. If the build is successful, it becomes available for testing.

When you have a successful build, click the Pass For Testing action.

The Pass For Testing window enables you to specify which analysts and/or groups are to test the build, and the type of test that is required. The Test Type list is populated with values from reference lists.

You can use the Pass For Testing action more than once, to enable further tests and testers to be added. A Release Management Testing Task is created each time the action is used. The release cannot progress until all of these Release Management Testing Tasks are completed.

You open the Release Management Testing Tasks from the Change Tree for the Release. The tasks can either be Passed or Failed.

If the testing is successful, the Release moves to the rollout stage; if the testing fails, the Release can either be Closed, or, if the failures are considered insignificant, can still be moved to the rollout stage.

Rolling out the Release

When the Release has been successfully tested, you can start to roll it out.The Release Roll Out Plan action displays the Release Roll Out Plan window, which displays the current Release Details window, and enables you to record the Roll Out Date and the Roll Out and Release Back Out Plans.

After you have completed the Rollout, you can complete the Release using either the Roll Out Successful or Roll Out Failed actions.