menu
Last updated on
Plutora Blog - Release Management

Release Management Process and Best Practices

Reading time 10 minutes

Enterprise software delivery is a complex process aiming to deliver multiple high-quality product releases quickly. Throughout the software delivery life cycle (SDLC) release management is one of the key practices that ensure organizational alignment, predictability, and quality software delivery.

What is release management

Release management has been a core process of software development for decades. The purpose of release management processes is to coordinate the development, operations and deployment of software while ensuring alignment with business priorities. In enterprise release management, these processes are built around multiple key goals:

  • Managing risk
  • Coordinating IT resources
  • Ensuring compliance and auditing processes
  • Overseeing the cutover to new versions
  • Maintaining alignment of the business with software development

The responsibilities for release management include everything from requirements gathering to managing planning, scoping, building, testing, and deploying. Release management has evolved with advances in technology and best practices but remains an essential process for both IT service management (ITSM) and software delivery. The focus or scope of release management has also shifted in that time from a cutover focus originally to an end-to-end process today. While the implementation will vary by SDLC, here are standard components of the release management process:

Release Management Process Components

Release Pipeline:
A specific release process from feature planning to delivery

Release Value Stream:
The release processes that add or create value across the release pipeline

Release Policy:
The definition of release types, standards, governance requirements for an organization

Release Template:
A single, repeatable workflow process for release pipeline that includes human and automated activities and follows an organization’s release policies.

Release Plan:
An instance of a release template developed for a specific release

Deployment Plan:
Activities to deploy a release to the production environment.

Release unit:
The set of artifacts released together to implement a specific feature

Release package:
A combination of one or more release units deployed together as a single release due to interdependencies, scheduling, or business priorities.

Major Releases:
Infrequent release packages that include often include many release units that have a high or critical business impact

Minor Releases:
More frequent release packages with fewer release units that do not include mission critical components.

The role of the release manager

The release manager role crosses departments and disciplines. They coordinate multiple stakeholders while ensuring a well-orchestrated release bringing together everyone on the same page from leadership to operations. It is a role that has always required T-shaped skillsets.  Release managers may be IT professionals specializing in coordinating release activities or upskilled product owners able to manage releases.

Regardless of their background, release managers work with business leaders, product owners, IT project teams, and operations staff to ensure every release contains the correct features that meet the technical requirements through pre-production environment testing, coordinates and schedules release unit dependencies into release packages and orchestrates a seamless release deployment. This includes working constantly to minimize any impacts to the customer experience. From proactive testing, to fostering team collaboration, to monitoring the health of the release can all improve release quality.

Release Management and Change Management

Release management and change management developed as separate processes that worked together to manage enterprise software. Change management led by a Change Approval Board (CAB) was responsible for managing the authorization of software changes. Release management was then responsible for the software development and delivery of these changes. This structure helps align software development with business priorities and ensure requirements compliance when large and infrequent releases carry significant risk.

This structure changes with transitions to agile development and DevOps. Ultimately, in DevOps continuous delivery each release carries minimal risk and automated tests verify requirements compliance. At this stage a CAB would dramatically slow development. The transition to DevOps is coupled with a shift away from change management to product management working in concert with release management. This transition is categorized by three phases:

  1. CAB approves software requirements changes and inspects work after development.
  2. CAB verifying work performed post-development with a mix of non-functional requirement verification, such as security tests, incorporated into the development process.
  3. Disciplined devops enables automated criteria gates to verify non-functional requirements during development.

Release Management Best Practices

Though release management has been an integral part of the SDLC for decades, there is no one-size-fits-all process. The process itself continues to evolve with software development frameworks, methodologies, and technologies and will be different within waterfall, agile frameworks, and DevOps methodologies. Instead, each organization needs to tailors the release management process to meet their needs using best practice concepts to inform their implementation.

Release Management in ITIL® ITSM

ITIL is the world’s most popular approach for IT service management, ITIL is developed and managed by AXELOS is a joint venture company, created in 2013 by the Cabinet Office on behalf of Her Majesty’s Government (HMG) in the United Kingdom and Capita plc, to manage, develop and grow the Global Best Practice portfolio.

ITIL V3: The service transition process

In ITIL V3, release management was called release and deployment management and part of the Service Transition processes, one of the 26 ITIL processes arranged along the service lifecycle. The service transition process is responsible for building and deploying IT services in a coordinated manner

ITIL V4: From processes to practices

ITIL V4 addresses an organization’s ability to capitalize on quickly changing technologies, by updating processes to 34 practices across general management, service management, and technical management. ITIL also introduces the service value chain (SVS), the combination of interconnected activities provides the operating model for the creation, delivery, and continual improvement of services. Each combination of activities that delivers a service is known as a value stream. The SVS also incorporates continual improvement, to provider ever greater effectiveness and efficiency and governance, to provide alignment for value streams. Overall, the SVS model creates a shared approach to service management in an organization, breaking down silos in the process by following guiding principles and practices instead of specific processes.

Release Management ITIL V4 - Service Value System
ITIL V4 – Service Value Chain

Release Management with Waterfall

Waterfall methodologies work best in situations where software product requirements can be well-defined up-front with a high degree of certainty. In a waterfall methodology, the definition of work is generally prioritized over the speed of delivery. To ensure that work definitions are stringently adhered to, a CAB must be set up to approve software product changes. The release manager is then responsible for creating and executing a release plan. As the release package goes through testing, any changes that are required to meet quality standards will then be reviewed by the CAB.  Finally, once a release has been accepted by the QA team, passed testing, or other stakeholder approvals as defined by the Release Policy, it is ready for deployment in the Production environment where end-users or customers will be able to access the new capabilities released.

Change and Release Management Process
Illustration of the overlap between the change and release management process

Release Management in Agile

Release management can be viewed as an inherently agile process as releases are incremental improvements to a software product at a particular cadence. Organizations are increasingly adapting agile frameworks as market disruptions become the norm. Agile methods allow for requirements to evolve over time through small iteration cycles. Agile itself is a framework with multiple implementation frameworks including Scaled Agile Framework (SAFe), Extreme Programming (XP), Feature Driven Development (FDD), Kanban and many others.

In Agile methodologies, the central role of the CAB is often replaced by a more decentralized change management process that can adapt requirements sprint by sprint. For example, in the scaled agile framework (SAFe), a popular Agile framework for large enterprises, release units are delivered every sprint cycle and a release package is deployed to production over 10-12 weeks of sprints. Through this release management process, SAFe allows enterprises to gain the benefits of agile with the control of waterfall. The release manager is the cornerstone of this process, continually coordinating with business stakeholders to ensure that the scope of each sprint aligns with business priorities and works with the development and operations team to coordinate their development, testing, and delivery.  If you want to learn more about Release Management and scaled agile framework (SAFe) take a look of our white paper: An Introduction to Release Management and Scaled Agile Framework (SAFe)

Deployment Planning

Cutover, or go-live, events in Agile likely include release packages containing several release units that need to be deployed in a specific sequence. These events can quickly become complex, increasing their risk of failure. To avoid long, stressful manually coordinated cutovers organizations implement Deployment Management & Orchestration solutions. These solutions enable teams to document the entire cutover process beforehand including each activity’s dependencies. The process is then streamlined by automating as many tasks as possible. With the deployment plan and task automation complete, cutover events can easily be orchestration in real-time. These solutions deliver work visibility to the entire teams, enabling everyone involved to see the status of each activity. This allows independent teams to act confidently throughout the cutover event, accelerating the process and reducing risks.

Release Management in DevOps

The increased collaboration, automation and decentralization of DevOps teams may at first appear to challenge the role of release management in the SDLC. However, release management is just as essential in DevOps environments as any other. Release management is responsible for creating the continuous flow to production that DevOps strives for while aligning work within the team and across the organization. 

While still critical, the release management process in DevOps looks different. Many large enterprises adopting DevOps implement a continuous integration and continuous delivery (CI/CD) pipeline but not continuous deployment. This allows enterprises to retain a level of centralization through release policies that include RACI requirements that incorporate leadership in deployment plans. 

At the same time DevOps cultures emphasize collaboration, experimentation, and continuous improvement through tight feedback cycles. This breaks down work and information silos, creating decentralized, product-oriented teams. Further, DevOps aims to constantly reduce the size of software changes to reduce the risk of disruption from any release. The automation of testing, building, integration, delivery, and other processes reduce the human activities in every release as well as the amount of management and coordination required. In these situations, the product owner often takes on the role of release manager, acting as the bridge between business, product, development and operations. Additionally, a centralized release management team can work with product owners to ensure that organization release policies are met and spread best practices across teams. This adaption of roles is reflected in ITIL V4’s practices describing sets of value streams and processes interacting differently depending on the circumstances.

Driving Continuous Improvement with Release Management

In DevOps, Agile, and even in waterfall, as new tools advance the SDLC, release management presents a tremendous opportunity to drive continuous improvement in software delivery throughout an enterprise. New tools capture more data, providing the opportunity for greater visibility and traceability throughout the release process that will elevate the effectiveness and efficiency of release planning and the review processes to accelerate and improve software delivery in large enterprises.

Plutora, the leading value stream management platform for enterprise IT, includes release management and deployment planning solutions. Plutora’s flexible release management module makes it easy to implement best practices in any SDLCs, including those with a mix of methodologies across the enterprise. From standardizing release requirements to real-time orchestration of pipeline activities, Plutora empowers enterprises to confidently streamline their release processes.  Plutora also includes a Deployment Management & Orchestration module. This module provides deployment planning, automation features, and real-time orchestration of cutover activities. Using Plutora, enterprises accelerate deployments, while making them more predictable and lower risk.