This documentation supports the 25.1 version of BMC Helix Change Management.To view an earlier version, select the version from the Product version menu.

Learning about Release Management


BMC Helix ITSM provides a release-tracking interface that is simple to learn and use. A release is a collection of related authorized changes to an IT service that are tested and introduced together into the live environment. BMC Helix ITSM provides capabilities to plan, build, test, and deploy controlled releases into your IT environment. The release managers, release coordinators, and the change advisory board in your organization can use BMC Helix ITSM to create release requests and manage them throughout their lifecycle. For example, you can use release management to implement or deploy an application or software on a large scale across the company.

Process overview

The following figure illustrates the lifecycle of a typical release request:

Release process1.png

Release milestones

A milestone is a significant event in the release project, which includes a major deliverable. For example, when you complete the Initiate milestone, you have successfully created a release request that has been approved by the CAB. The lifecycle of a release request consists of the following milestones:

Initiate

Allen Allbrook, the release coordinator, creates the release request. The release must be divided into several changes and activities. Allen creates and schedules these in a release plan. A release plan provides a consolidated view of the tasks that the release management team must perform to drive the completion of the change requests and activities required to close the release. Allen performs the following actions:

  • Creates a change request to install the new server for the payroll service at the Deployment milestone. He assigns the change request to Mary Mann, the change manager.
  • Creates an activity to train employees on the new payroll service. He assigns it to Francie Stafford, the activity assignee. 

If an unforeseen situation arises, Allen can create or add changes and activities at later milestones.

If your application administrator has configured milestone phases, Allen can specify that the staff must work on their change requests and activities at a certain phase (for example, installing the server at Phase 1 or training users at Phase 5 of the Deployment milestone). However, if no phases are mapped out of the box for Calbro Services, he blocks out a time segment to work on the release by indicating the scheduled start and end dates. Larger projects can include planning all the releases and changes approved for implementation. 

Important

If an approver is mapped to the approval phase, the release approver must approve the release request before it can move to the Planning milestone. A release usually includes multiple approvals. However, if no release approvers are mapped out-of-the-box for Calbro Services, your application administrator must configure them.

Plan

Allen reviews the release plan. He opens the calendar and views the current schedule of releases, change requests, and business events for any potential conflicts. He adjusts the start and end dates according to the dates in the calendar. 

Release plan_2.png

Allen reviews these requests for change with Mary Mann, the change manager of the service for which the release is to be implemented. Together, they divide the requirements of the different change requests amongst them and they draft a high-level implementation plan that indicates the duration of each change, and the dependencies between these changes. Because they have added change requests, they obtain approval for the release plan. 

Francie Stafford, the activity assignee plans to add training tasks to the activity that will be implemented in the last deployment phase. Trainers must provide training and user documentation to all Calbro Services staff. She attaches a training schedule in the activity.

Build

Allen establishes the approach to build the controlled environments before the release goes into production. For example, after the release plan and a change request have been approved, he oversees the final build delivery of the new service. The build milestone assembles the CIs that are needed to create the release package before the service is released.

Test

The release coordinator makes sure that the CIs, IT service, or process meet their specifications and requirements. When all the tests have been completed satisfactorily, the release coordinator seeks approval from the change manager before deploying the package.

Deployment

The release is rolled out to the business. In this use case, the change request and release activity that make up the release are marked Closed during the deployment milestone:

  • Mary Mann, the change manager, opens each change request and moves it to the Implement stage. She creates the installation task and assigns it to Ian Plyment, the task implementer. He installs the new server. Mary then closes the change request. Mary creates and assigns the tasks for the remaining change requests. After the tasks are performed, Mary closes the change requests.
  • Francie Stafford, the activity assignee, executes the training activity. When all the trainers finish their tasks, she marks the activity as Completed.

Close down

The release request enters the Close Down milestone. Reviewers provide feedback on the effectiveness of the release, and record metrics for deployment to make sure the release met its service targets. Allen verifies there is minimal unpredicted impact to the IT infrastructure and makes sure that the users are satisfied with the user documentation and training.

IT Support user roles

The following table explains the IT Support user roles.

User

Release Management role

Function

More information

Allen Allbrook

Release Coordinator

Reviews the RFCs for the services for which he acts as the release coordinator after they have been passed on from Change Management. He organizes and facilitates the CAB meetings for the services for which he acts as the release coordinator. Allen splits the requirements of releases into logical groups that can be handled efficiently by change managers. He prepares a business case for a new release when additional funding is needed for its implementation. He initiates the implementation of releases and decides on corrective actions as needed. Finally, he organizes and conducts post-implementation meetings to collect improvement suggestions for future releases.

Ensure that Allen Allbrook has Release Master or Release User permissions.

Mary Mann

Change Manager

Reviews the risk and impact analysis to make sure that the assessment has been performed thoroughly. Mary makes sure that appropriate actions have been planned to minimize both the risk of failure and the impact on users during change implementations. She makes sure that the timing of planned implementations does not conflict with other planned changes or events. 

Mary uses the Change Management Console as the entry point for managing change requests. She opens the change request to handle the specific details of the change request. If Mary is given Release Viewer or Release User permissions, she can use the Release Management Console as the entry point for managing release requests. She opens the release request to review the overall details of the release request.

Ian Plyment

Task Implementer

Performs the tasks associated with a change request. In this example, Ian's responsibility is to install the new server.

Ian performs the installation task associated with the change request.

Francie Stafford

Activity Assignee

Performs the activities associated with a release request. This role can be a staff member or a group. For example, a release request to install a new software application might include activities like creating training materials and training employees.

If Francie is given Release Viewer and Activity User permissions, she can use the Activity form to perform the activities that are associated with a change request.


The following video explains the Release Management process flow.

Disclaimer

Although the concepts and procedures presented in this video are correct, the user interfaces shown are not current.

icon_play.pnghttps://youtu.be/qGZEXkPcx7A

Testing your knowledge

Check your knowledge. See if you can answer each question. Click the questions to view the answer.

When should you consider using the release management process instead of the change management process?

You use the release management process to implement or deploy an application or a software on a large scale across the company. A release is a collection of related authorized changes to an IT service that are tested and introduced into the live environment together.

What is a release plan?

A release plan provides a consolidated view of the tasks that the release management team must perform to drive the completion of the change requests and activities required to close the release. 

During what phase are change requests closed?

During deployment, change requests and related activities are closed.

Do you want to learn more?

For more information about creating release requests, see Initiating-and-modifying-a-release-request.

For more information about approving release requests, see Approving-a-release-request.


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*