Milestones in the release request lifecycle
The release request process uses the following business scenario to explain Release Management features and processes. Calbro Services must install a new payroll service by a certain date. The release coordinator initiates a release request to install the new application. To complete the release, the release coordinator must perform the following work items:
- Create a change request to install the server that runs the application
- Create an activity record to train users on the new application
A release request tracks the progress of a release through its entire lifecycle, from the Initiate milestone to the Close Down milestone. The Process Flow Status bar on the Release form steps you through the release process from the Initiate to the Close Down milestone. It provides a visual mechanism to track the milestones of a release request.
Process Flow Status bar on the Release form
Your application administrator might have configured milestone enforcement in Release Management. Milestone enforcement requires that all change requests and activities must be completed before the release can move to the next milestone.
To work a release request from start to finish, the user roles listed in the table below are required. Although the responsibilities of these users can vary from organization to organization (and in some organizations, one person can fulfill several roles), they generally include the following roles and functions.
If the Calbro Services sample data is installed on your server, you can log in to Release Management as these users and follow the use cases with some simple modifications in their permissions.
IT Support user roles
Release management role
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.
Reviews the risk and impact analysis to make sure that this 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. Finally, Mary obtains approval for changes.
Support staff member who performs the tasks associated with a change request. In this example, Ian's responsibility is to install the new server.
Ian performs the install task associated with the change request.
Staff members or groups who perform the activities associated with a release request. For example, a release request to install a new software application might include these activities: Create training materials, Train 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.
A release usually includes multiple approvals, depending on your business needs.
The following table walks you through 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.
Allen Allbrook the release coordinator creates the release request. When 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, you can specify that 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). But no phases are mapped out-of-the-box for Calbro Services. He then 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. But no release approvers are mapped out-of-the-box for Calbro Services. Your application administrator must configure them.
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. 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.
|Allen establishes the approach to building 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.
|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 Remedy Change Management for the actual deployment.
|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 the users are satisfied with the user documentation and training.
The following video explains the Release Management process flow.
Although the concepts and procedures presented in this video are correct, the user interfaces shown are not current.