Skip to end of metadata
Go to start of metadata

Release Management

The goal of release management is to allow planning and deployment of releases into live environments.  A release can be linked to one or more change requests or service requests and those requests and their tasks will be visible within the release record.

Releases are based on Release Types, which are preconfigured with documentation and task workflows that may include the approvals necessary to proceed with the release.

Release Layout

The release layout consists of several tabs of information.

Details Tab

The Details tab of the layout has the main fields that identify the owners of the release and other general information about the release.

Release details tab screenshot

When the Release Type and Version is selected, this pulls in the Release Readiness Criteria and Acceptance Criteria and Checklist documents that are attached to the release type, and these documents provide the details for how the release should proceed, what the go / no go criteria are, and so on. Fields for Build Manager, Change Manager, and Test Manager identify the main decision makers and drivers of the release process. There are also fields used to specify the risks involved with the release, the backout plan, and the test plan.

CIs and Change Requests Tab

The CIs and Change Requests tab is used to select the configuration items for the release.  From here you will be able to view the graphical display of the CI's to see any dependencies or downstream CI's that will be affected by the release.

If any definitive media is involved, those records can be looked up and pulled into the Definitive Media table. In addition, you can search for any outstanding change requests and link them to the release. 

The change request can alternatively be linked to the next release record from within the change request. The Configuration Items from Change Requests table can display all of the CIs linked to the selected change requests.  Clicking the Refresh CIs button pulls in all of these CIs by querying the change requests.

Schedule and Tasks Tab

The release start and end window is defined on this tab.  To help in setting these values, the system populates the Earliest CR Start Time and Latest CR End Time with values based on the linked change requests and their own change window fields.  These fields are informational only.

In addition, any task workflow is shown here and tasks are generated and launched from this screen.

Screenshot of the task workflow fields

Releases support complex task workflows with approval tasks mixed in with CI change tasks, and sophisticated branching of tasks possible.  Some default task workflows have been defined to demonstrate this capability.  Here is a sample workflow for a software applications upgrade.

Active Release Tasks sample workflow.

The Status column shows the progress of the tasks.  Currently the task in sequence 2 is assigned and the rest of the tasks are waiting for their prerequisite to be completed.  The Sequence indicates the relative order of the tasks.

The Task Diagram icon can be clicked to show the relationship between all of the tasks.  What follows is a portion of the diagram for the sample tasks, showing that this is a branching sequence of tasks that come back together near the end of the process.

Change Request Tasks

If change requests have been linked in and they also have tasks, the change request tasks will be shown below the release tasks.

Change Request Tasks table.

Related Records Tab

This tab shows any related knowledge articles, incidents, and service requests related to the release.  New service requests for equipment or license purchases can be generated directly from within the release in order to be sure the proper goods are provisioned prior to doing the release.

Automation and Processing

When a release record is created, its priority is set by a rule based on the Impact and Urgency values.  Releases have their own priority group and matrix that defines the mapping.

An email is also sent to the Change Manager, Build Manager and Test Manager for the release, notifying them about the release. Whenever the status of the release changes, the same three people are notified by email.

When all tasks for the release have been completed, the release status automatically updates to Completed.

If the Urgency or Impact change after the release is created, the system updates the priority to the correct value.

The rest of the notifications and automation for a release are typically handled through the tasks as they are launched and completed.


There are a couple of reports on the releases table.  An example is Number of Releases by Release Type in last 6 months.

Chart showing number of releases by release type in last six months

  • No labels