Release management: it’s different to change enablement!

Many people have heard about the confusion between the ITIL incident management and problem management practices. But this is not the only area where people might get different ITIL practices confused, with another scenario being the release management and change enablement (formerly change management) practices.

The ITIL 4 release management practice guide states: “The purpose of the release management practice is to make new and changed services and features available for use”. IT service management (ITSM) authority Stuart Rance clarifies that: “release management is about making new and changed things available to people and not the deployment of the technology”. This brings in another ITIL 4 practice where confusion with release management can arise: deployment management.

In contrast, the purpose of the change enablement practice is: “to maximize the number of successful service and product changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule”.

A release can be structured in different ways (relative to changes):

• One change to one release  This direct mapping of changes to releases is suitable for smaller projects.
• Many changes to one release  Where multiple changes are bundled into a single release and deployed together. For example, when bug fixes and enhancements to a large application are released together.
• One change to many releases  Where a single change is delivered through multiple releases. For example, the deployment of a large corporate system. Or, in the context of ITSM, the phased implementation of an ITSM tool and its breadth of capabilities.

The primary objective of change enablement is to enable changes with minimum disruption to IT services. This objective is achieved using standardized methods and procedures that balance change need and the potential detrimental impact. It involves assessing the risk, impact, and benefit of the change.

Release management takes a holistic view of an IT service’s change(s) to ensure that all release facets are considered together. Importantly, release management ensures that all infrastructure components are properly integrated, tested, and compatible with existing systems; this is outside of the remit of change enablement.

At a more granular level, change enablement activities include logging, assessing, and authorizing changes, conducting change advisory board (CAB) meetings, managing change schedules, and closing change requests. In contrast, release management activities include planning, designing, building, configuring, testing, and deploying releases (using deployment management best practices).

If it helps, change enablement can be viewed as a governance process that enables business innovation and protects business stability through risk management. In comparison, release management is focused on actions where, based on change enablement authorization, it builds and tests releases of new or updated services for the production environment. 

Much of the confusion between the change enablement and release management practices comes from two causes:

1. People talking about ‘change and release management’ as though it is a single thing. It can be, but it might mean that the specific purposes of change and release activities, and the differentiation, are not fully understood.
2. ITIL training and consequently adoption has traditionally focused on change management (and then change enablement for ITIL 4) such that, as with a right-handed individual preferring their right hand over their left, change is the stronger of the two ITSM capabilities in terms of people’s knowledge and understanding.

The first of these can also be levied against what was ‘release and deployment management’ in ITIL v3/2011 and is now separate release management and deployment management practices in ITIL 4.

The main impact is when one or both change enablement and release management capabilities suffer because of the confusion. It might be that the change process assumes that release is doing something that it is not, or it undertakes release management responsibilities unnecessarily. For example, a CAB meeting might waste time evaluating the validity of the testing process when this should be a release management responsibility.

Or that release management assumes that change enablement has already done something it should do; for example, the testing of changes.

As an extension of this, it might be that corporate focus is placed on one practice over the other; so much so that strong change enablement capabilities are followed by insufficient release management or vice versa.

This potential for confusion can also translate into DevOps environments where change and release are more integrated.

The DevOps approach affects both change enablement and release management capabilities. For change, the relevant DevOps capabilities that then affect release management include:

• Infrastructure as code Where infrastructure changes are handled through code in an automated, repeatable manner.
• Automated testing Which ensures quality and correctness before changes are merged into the main codebase.
• Automated deployment Where changes are automatically deployed using continuous integration/continuous delivery (CI/CD) pipelines.

From a release management perspective, there is the abovementioned CI/CD (which automates releases) plus:

• Feature flags These allow developers to enable or disable features in production in order to test new features with a small group of users, quickly disable problematic features, or perform canary releases.
• Canary releases Where new features are first released to a small subset of users to test the operational impact.
• Blue-Green deployments A release management strategy where two environments (Blue and Green) are used to reduce risk and downtime.

Arming yourself with a clearer understanding of what differentiates release management and change enablement will hopefully prevent much of the confusion that occurs and eliminate the adverse consequences this can have on your service management processes.