Release Management Process

Release and deployment management defines a standardized process for planning the getaway, building and testing the release, scheduling the release, pushing the release, deploying the release, providing early life support (ELS), and closure of releases.

Release Management Process flow

In a practical IT environment, release management operations would generally be executed as per the below diagram:

Download This Template

 

Release Management Process flow

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). The release can be a standard 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

The 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 the vendor’s device 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

The 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 the 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 building activity is completed as per the Release plan. The 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 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 and 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 following environment

Step 6: Service validation and testing

Build prepared by the build team is then moved into Test Environment for testing. The Release Manager will initiate testing as per the Release Plan. The service Validation & Testing team will complete the release testing and provide test results to the Release Manager. Build and Test activities will be completed in the stipulated time frame as per the Release Plan. The 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 the Change Manager and other stakeholders. Release Manager will also ensure that the 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 send out a communication to all stakeholders. Acceptance criteria for the release are documented wherever relevant in the release ticket. Successful disclaimer (s) with the positive test results is now moved to the deployment phase.

Step 10: Deployment readiness activities

A 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, the Delivery Manager will give Go/ No-Go decision regarding the releases. The 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

The Release Manager will coordinate and ensure that the backup is taken for the current release. This is to ensure that rollback to the previous baseline is possible if the deployment of the release fails.

Step 12: Deploy release as per plan

The release is deployed in the environment as per the deployment plan. Release Manager broadcasts the downtime-related information wherever necessary in advance.

Step 13: Test Deployment

The success of the deployment is tested during this activity. The Release Manager will conduct the health check in coordination with the deployment team to verify the success of the deployment.

Step 14: Change evaluation

The change evaluation process will evaluate the release.

Step 15: Change Management

The 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 freedom and restore the services to the normal stage. A root cause analysis for the release’s failure may be triggered (on a need basis) via the Problem Management process.

Step 18: Change management

Change Management will ensure updates to the RFC and related updates to the requester. Required communication regarding the 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. The Release Manager 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. SACM Configuration Manager will update the CMDB with the new or updated CI details.