ITIL Release Management Process
Release and deployment management defines a standardized process for planning the release, building and testing the release, scheduling the release, testing the release, deploying the release, providing early life support (ELS), and closure of releases.
Release Management Process flow
In practical IT environment, release management operations would generally be executed as per the below diagram:
Process Description of Release Management
Step 1: Create a release ticket
Request for Change (RFC) from the Change Management Process forms an input to Release & Deployment Management process.
For all Releases, a Release ticket is raised in <<tool>> and is to be tagged to the RFC which triggered the Release.
There may be many to one mapping between changes and releases (i.e. many changes can be released together) or one to one mapping (i.e. one change can be released stand alone).
Release can be a normal release (Major or Minor) or an emergency Release.
Step 2: Create a release plan
For every release, the Release Manager will own the responsibility of preparing a Release Plan. Release Manager coordinates with Change Management team and Build team regarding the same.
The Release Plan will be submitted to the CAB.
Step 3: Assign release activities to technical teams
Release Manager will assign the release activities in <<tool>> to the person responsible for those activities.
- These tasks are tracked and monitored by the Release Manager to monitor the release status.
- If a release needs a vendor involvement, then the ticket is assigned to the vendor queue in <<tool>> and <<if tool integration exists it is routed to vendor’s tool via the B2B the ticket gets created in their system>>.
- Release Manager will then publish the release calendar based on the dates finalized in the Release Plan.
Step 4: Release packaging
Release Manager will ensure that releases are packaged and released in a controlled manner as per the plan.
Release packaging includes assembling and integrating the release components as per the dependencies identified.
Step 5: Build the release
Release Manager will coordinate with Build team to build the release and produce the build document which will contain:
- Build, installation and test plans, procedures and scripts
- Monitoring and quality assurance of the release
- Processes and procedures for distributing, deploying and installing the release into the target environment
- Release unit roll-back procedures
- Change remediation steps in case of release failure
Release Manager will coordinate with Build and Change Management teams and ensure that the build activity is completed as per the Release plan.
Build team will consider various aspects relating to version control, baseline management, control of inputs and outputs from a build.
Creation of a configuration baseline which is recorded in the configuration management tool for the release before and after installation, to provide a restore point in case of rollback is initiated by the Release Manager along with the Change and Configuration Manager.
Other aspects taken into consideration for a Release are:
- Checking that the security requirements are met
- Verification activities to ensure prerequisites are met before a build or test begins
- Preparing and controlling the service release readiness for deploying into the next environment
Step 6: Service validation and testing
Build prepared by the build team is then moved into Test Environment for testing. Release Manager will initiate testing as per the Release Plan. Service Validation & Testing team will complete testing of the release and will provide test results to the Release Manager.
Build and Test activities will be completed in the stipulated time frame as per the Release Plan. Time allocated to each activity will depend on the release type.
Step 7: Test successful ?
Release Manager will ensure that all mandatory tests are conducted and all tests are successful before a release can be flagged off to production.
Step 8: Update Release Plan & Rollback Plan ?
Once testing is successful, Release Manager will update the Release Plan and rollback plan as required and circulate the same to Change Manager and other stakeholders.
Release Manager will also ensure that Rollback plan is properly prepared and is tested (or verified wherever testing of rollback plan is not possible).
All releases will be subject to pre-implementation checks and the Release Manager will work with the Change Manager for changing, reassessing, and rescheduling unsuccessful release packages.
Step 9: Release preparation and communication
Release Manager will ensure that all the environments are ready for release and will send out a communication to all stakeholders.
Acceptance criteria for the release are documented wherever relevant in the release ticket.
Successful release(s) with the positive test results is now moved to deployment phase.
Step 10: Deployment readiness activities
Readiness assessment for the deployment group will be done to check for issues and risks in delivering the current release that may affect the deployment.
For all non-major Releases, Delivery Manager will give Go/ No-Go decision regarding the releases.
Deployment team will prepare the training plan, training material, training schedule and training communication (for all major releases). Before the deployment they will ensure that the users, relevant support teams and other concerned stakeholders are appropriately trained.
Step 11: Initiate backup
Release Manager will coordinate and ensure that the backup is taken for the current release. This is to ensure that rollback to previous baseline is possible in case the deployment of the release fails.
Step 12: Deploy release as per plan
Release is deployed in the environment as per the deployment plan. Release Manager broadcasts the down-time related information wherever necessary in advance.
Step 13: Test Deployment
Success of the deployment is tested during this activity. Health check will be conducted by the Release Manager in coordination with the deployment team to verify the success of deployment.
Step 14: Change evaluation
Change evaluation process will evaluate the release.
Step 15: Change Management
Change management process will own and perform the Post Implementation review (PIR).
Step 16: Rollback required due to failed change?
During PIR Change Management will decide on the success or failure of the change.
Step 17: Rollback release
If a release fails, Release Manager will authorize (on the advice of <<Customer>> Delivery Manager or Change Manager) and initiate a Rollback of the release and restore the services to normal stage.
A root cause analysis for the failure of the release may be triggered (on need basis) via the Problem Management process.
Step 18: Change management
Change Management will ensure update to the RFC and related updates to the requester. Required communication regarding failure of change will be sent as per the Change Management Process.
Step 19: Update and close release ticket
Release Manager will resolve the release ticket and pass on the status update and post-implementation status to Change Management and update/ close the release ticket accordingly.
Release Manger will update the RFC with release closure comments.
Step 20: (If the change fails): Ensure CMDB update
Release Manager will ensure that the CMDB is updated with new (or updated) configuration details as per the release documentation and that a new baseline is created in the CMDB.
Configuration Manager will update the CMDB with the new or updated CI details.