Learning about Release Management
A release request tracks the progress of a release through its entire lifecycle, from the Initiate milestone to the Close Down milestone.
The following table describes each of the milestones of a release request lifecycle. In the Release Management module, 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.
Milestone | Description |
|---|---|
Initiate milestone | Allen Allbrook, the release coordinator, creates the release request. The release must be divided into several changes and activities, Allen can create and schedule these in a release manifest. A manifest provides him 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. He performs the following actions:
If an unforeseen situation arises that he did not anticipate, he 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. He then budgets the estimated costs and rolls up the risk levels from all the related change requests. Release Management rolls up of costs, budgets, time, and resources. Collision detection is automatically run when he saves the release. The Collision Detection tool determines if there are other change requests scheduled to work on the same CI during the same scheduled time, and helps him manage and resolve these potentially harmful conflicting change requests. 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. However, if no release approvers are mapped out-of-the-box for Calbro Services, your application administrator must configure them. |
Plan milestone | Allen reviews the release plan. He opens the change 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 change calendar. 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 RFCs amongst them and they draft a high-level implementation plan that indicates the duration of each change, and the dependencies between these changes. Because there are multiple change requests, they run Collision Detection again and 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 includes costs and attaches a training schedule in the activity. |
Build milestone | 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 milestone | 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 BMC Helix ITSM: Change Management for the actual deployment. |
Deployment milestone | 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:
|
Close Down milestone | 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. |
The following video explains the Release Management process flow.
https://youtu.be/qGZEXkPcx7A