Release and Deployment Management Workflow

The Release Management category includes seven phases, which follows the recommended Information Technology Infrastructure Library (ITIL) process by providing you with a set of approvals and tasks that you can expand.

The Release and Deployment Management workflow is illustrated in the following figure:

Release Registration and Assess

Releases may be raised either as the result of advanced planning activities, so they are coordinated with planned maintenance windows, or in response to a change request or group of change requests. The release should contain changes that are planned to be executed together, either because they all affect the same service or because they will be executed during the same release window. During the Assess phase the importance and value of the release should be determined and documented in the release record.

Plan and Design

Plan releases in line with requirements resulting from approved changes. Analyze all the affected Configuration Items (CIs) and CI Groups, review what software or hardware is needed to accomplish the plan, and determine the cost. This phase requires the plan and design approval before going to the next step.

Build and Test

Build effective release packages for the deployment of one or many changes into production. Test release mechanisms to ensure minimum disruption to the production environment. During this phase the individual changes that make up the release will be built and tested in isolation as part of the change management process and the combined release package will be built and tested as well. This phase requires that the build and testing of the release has been approved before going to the next phase.

Training

Identify and fulfill training requirements for various users. This phase is optional and is activated when you select high Impact Assessment and high Urgency for the release change.

Deployment

During the deployment phase of the release the individual changes that make up the release will be implemented in a coordinated fashion in order to maximize the likelihood of success while minimizing the required service disruption. The implementation of each individual change is executed and tracked in the Change Management process.

Back Out

The back out phase is an optional phase that is entered if the release encounters an issue during the deployment phase and the work done for the release must be undone. The work required for back out will have been determined and recorded during the build and test phase.

Verification and Release Closure

After the release is completed, the results must be report for evaluation to those responsible for managing releases and then presented for stakeholder agreement. This process involves analyzing the results for the changes that make up the release and the closing of related user interactions, incidents, and known errors. The verification phase is performed to confirm that:

• The release met it objectives
• The release requestor and stakeholders are satisfied with the results
• Lessons learnt are incorporated in future releases