The goal of release management is to enable an organization’s systems and services to change in response to changing business needs. Release management may be solely concerned with the technical deployment of IT products and features in some organizations, but it may also include adoption and business process changes in others.
In ITIL, what is Release Management?
One of the main processes in the Information Technology Infrastructure Library (ITIL) framework’s Service Transition section is release and deployment management. ITIL is the most widely used framework for technology product and service governance. It enables businesses to deliver high-quality, customer-centric, and cost-effective products and services.
Release Management Process:
Depending on the unique dynamics of each organization or application, the specific steps of release management will vary. The sequence listed below is the most common process of release management.
Stage 1: Requesting:
Requests for new features or changes to existing functions are the starting point/initial point for release management. Each and every request is assessed for its logic, feasibility, and whether it can be fulfilled by reconfiguring an existing application version in production. It provides guidelines and support for release deployment, as well as roles involved in other aspects of the release and deployment management process.
Stage 2: Planning:
A solid plan keeps the release team on track and ensures that all requirements are met, and it is the most crucial stage in the development of a release. The structure of the release is defined here. Stakeholders can refer to workflow or checklists at any time during the release process, including scope and milestones, as well as responsibilities.
Stage 3: Building and Designing App:
This is the stage at which the requirements are translated into code. The release has been designed and implemented as executable software. It primarily focuses on the actual development of all required release components, including the issuance of all necessary work orders and purchase orders for vendor-sourced components, as well as the readiness of release components for validation and testing.
Stage 4: Testing:
When a release is finished, it is sent to testing, where it is subjected to non-functional and functional testing. If bugs are discovered, the software is sent back to the developers to be tweaked before being tested again. This process continues until both the development team and the product owner have given their approval for the release to be deployed in production.
Stage 5: Deploying:
The release is deployed and made available to users in a live environment. The term “deployment” refers to more than just installing a release. It entails informing users about the changes and training them on how to use the system with the new features in mind.
Following deployment, the release enters the support phase, where any bugs that may require a change request are recorded. As a result, the cycle starts all over again.
Stage 6: Release Closure:
It entails formally concluding release activities, ensuring that all documents and records are up to date, and communicating release outcomes and feedback to project teams.
Approaches to Release Management
Most businesses use some variation of these approaches, though they may be referred to differently. Different approaches are also commonly used for different types and sizes of projects. The following are the types of approaches to release management.
- The Big Bang Approach entails deploying a new or modified service to all users at the same time.
- A phased approach is used, in which services are initially deployed to a subset of the user base, and if no problems are discovered, the deployment is repeated to other user groups via a scheduled rollout plan.
- Using automated approach/workflows and distribution mechanisms, changes are deployed into the production environment.
- Using the push approach, the target audience from different locations gets the service components deployed from a central location.
- Using the Manual Approach focuses on the manual tasks to distribute a press release (Used when the release has system dependencies that require manual checking before or after deployment).
The Release Manager’s role in release management
A manager must oversee the release management process flow, though they may choose to delegate some of their responsibilities to subordinates. The release manager’s responsibilities usually include the following:
- Working closely with IT release managers from various portfolios across IT to build the IT release calendar and centralize the view of all releases.
- Assist with project management and interdependencies to ensure that milestones are met and the release’s integrity can be measured.
- Managing multiple application releases, scheduling, and coordination across various portfolio streams across the enterprise.
- Manages risks and issues that affect the scope, quality, and timeliness of the release.
- Conduct Release Readiness Assessments, Business Assessments, and Milestone Assessments.
- Participate in CAB meetings to discuss the scope of the release and/or potential roadblocks.
- Manage and report to Senior IT Management and Business Management, as well as provide meeting updates.