Release management

A change makes something different; a deployment moves it into an environment; a release makes it available for use. These three ideas are easy to blur, and organizations that blur them often struggle. They treat every deployment as a big event with users, or they ship features nobody was told about, or they hold finished work for months waiting for a "release window". ITIL 4 separates the practices so organizations can manage each well. This lesson covers release management; lesson 7 covers deployment management. ITIL-140 covered change enablement.

Purpose of release management

In plain words, the purpose of the release management practice is to make new and changed services and features available for use. A release is a version of a service or other configuration item, or a collection of configuration items, that is made available for use. The key phrase is available for use. A release is about users and customers gaining access to something new, which involves more than technology: documentation, training, communication, support readiness and sometimes commercial and legal steps.

Release management plans what goes into a release, when and how it will be made available, and how the organization and its users will be ready. It coordinates with change enablement, which authorizes changes; deployment management, which moves components into environments; service validation and testing, which checks that they work; knowledge management, which prepares articles; and the service desk, which must be ready to support users.

Separating deployment from release

Modern practice separates deployment from release. Code can be deployed to production but hidden behind a feature flag, so it is present but not yet available to users. The release then happens when the flag is switched on, perhaps for a small group first. This separation reduces risk: deployments can happen often, during working hours, with small changes, while releases to users can be timed to suit the business, communicated properly and reversed quickly by switching the flag off.

Release models and cadence

Organizations release in different ways depending on their services, users and technology. In a traditional model, many changes are bundled into a large release on a fixed schedule, such as quarterly. Big releases are easier to communicate and train for, but they carry high risk: many changes land at once, problems are hard to isolate and rollback is difficult. In a continuous model, small releases happen frequently, sometimes many times a day, as soon as each feature is ready. Small releases carry less risk each, but users may find constant change disruptive unless it is managed carefully.

Many organizations use a mix. Internal components might be released continuously, while changes that affect user workflows, such as a new screen in the warehouse management system, are grouped into regular, well-communicated releases. Vendor software often arrives in releases set by the vendor, such as a twice-yearly cycle for a software-as-a-service platform, and the organization must decide how to adopt each one.

Phased releases and rings

Phased release, sometimes called ring release, makes a change available to progressively larger groups. A typical pattern for Larchmont might be: ring 0, the IT team; ring 1, a pilot group of volunteers in one distribution centre; ring 2, one region; ring 3, everyone. Each ring runs long enough to surface problems before the next begins. Device and desktop updates, such as operating system upgrades, are often handled this way. The same idea applies to features turned on by flags.

Phased release depends on good monitoring and feedback. If nobody watches the pilot group's incident rates, satisfaction and business metrics, the phases add delay without reducing risk. Release management should define in advance what evidence is needed to move to the next ring and what would trigger a pause or rollback.

Planning a release

Release planning answers several questions. What is in scope: which changes, features and fixes? Who are the affected users and customers, and what do they need to know or learn? What are the dependencies: does this release need a database change, a supplier update or a network change first? What are the acceptance criteria, and who confirms they are met? When should the release happen, given business calendars, freezes and other changes? How will success be measured? How will the release be reversed if needed?

For Larchmont, release planning must respect the business calendar. Peak season runs from mid-November to the end of December, when freight volumes double. Releases that change dispatcher or warehouse workflows are avoided during peak, and major ones are scheduled for late January or the summer, when volumes are lower and staff can attend training.

Release readiness

A release is ready when the technology works and the organization is prepared to use and support it. Readiness checks typically include: testing completed and acceptance criteria met; changes authorized; deployment verified in a production-like environment; knowledge articles and user guides published; service desk and support teams briefed; monitoring updated for new components; communications sent; training delivered where needed; and support arrangements with suppliers confirmed. Many organizations use a short go or no-go meeting or an automated checklist in their pipeline to confirm readiness.

Readiness is where release management meets the service desk and knowledge management from ITIL-140. A release that surprises the service desk generates confused contacts and poor first contact resolution. Briefing agents and publishing articles before the release turns a potential wave of incidents into routine questions.

Release versions and naming

Release management keeps track of what is in each release and which version is where. Many software teams use semantic versioning, a convention of major.minor.patch numbers: a major version change signals incompatible changes, a minor version adds functionality compatibly and a patch fixes bugs. For example, moving from 8.4.2 to 8.5.0 adds features without breaking compatibility, while moving to 9.0.0 may require changes by users or integrated systems. Clear version information, recorded in the CMDB and release notes, helps support teams diagnose issues and helps users know what changed.

# Classify releases by semantic version change and check upgrade paths
def parse(v):
    return tuple(int(x) for x in v.split("."))

def kind(old, new):
    o, n = parse(old), parse(new)
    if n <= o:
        return "not an upgrade"
    if n[0] > o[0]:
        return "major: may break compatibility, plan user and integration changes"
    if n[1] > o[1]:
        return "minor: new features, backward compatible"
    return "patch: fixes only"

history = ["8.3.7", "8.4.0", "8.4.1", "8.4.2", "8.5.0", "9.0.0", "9.0.1"]
for a, b in zip(history, history[1:]):
    print(f"{a:>6} -> {b:<6} {kind(a, b)}")
print("8.4.2 -> 8.4.2", kind("8.4.2", "8.4.2"))

 8.3.7 -> 8.4.0  minor: new features, backward compatible
 8.4.0 -> 8.4.1  patch: fixes only
 8.4.1 -> 8.4.2  patch: fixes only
 8.4.2 -> 8.5.0  minor: new features, backward compatible
 8.5.0 -> 9.0.0  major: may break compatibility, plan user and integration changes
 9.0.0 -> 9.0.1  patch: fixes only
8.4.2 -> 8.4.2 not an upgrade

Release notes and communication

Users need to know what is changing, why, when and what they need to do. Good release notes are written for their audience. Technical teams need a list of changes, known issues and dependencies. Users need a short explanation in plain language, focused on what they will notice and how it helps them, with links to guides. Customers of external services may need advance notice of changes that affect integrations or contracts. For larger releases, communication may begin weeks ahead and include demonstrations, champions in each team and drop-in sessions.

Releases from suppliers

Much of what reaches users comes from suppliers: software-as-a-service platforms that update on their own schedules, vendor patches and new versions of packaged software. Release management for supplier releases involves monitoring vendor roadmaps and release notes, assessing the impact on users, integrations and customizations, testing in advance where the vendor provides preview environments, preparing users and support teams, and deciding when to adopt updates that are optional. Some software-as-a-service providers allow customers to delay a release for a limited time; others do not, which makes early preparation essential.

Measuring release management

Useful measures include the share of releases delivered on the planned date; the share that met acceptance criteria; the number of incidents in the days after a release compared with a baseline; the share of releases reversed; user satisfaction with communication and training; and the lead time from a feature being ready to its release to users. The DORA metrics introduced in ITIL-140 lesson 8, such as deployment frequency and change failure rate, focus on deployment and change, but they give release managers important context about how quickly and safely the organization can deliver.

# Post-release incident uplift: compare incidents in the 7 days after each release with a baseline
import random, statistics
random.seed(1406)
baseline_daily = 18.0                       # average incidents a day for the service
releases = ["R-31", "R-32", "R-33", "R-34", "R-35", "R-36"]
effects = [1.05, 1.40, 0.95, 1.10, 1.85, 1.00]  # hidden multipliers; in practice unknown
print(f"{'release':<8}{'7-day incidents':>17}{'expected':>10}{'uplift':>9}  verdict")
for r, eff in zip(releases, effects):
    week = sum(max(0, round(random.gauss(baseline_daily * eff, 4))) for _ in range(7))
    expected = baseline_daily * 7
    uplift = (week - expected) / expected * 100
    verdict = "investigate" if uplift > 20 else "normal range"
    print(f"{r:<8}{week:>17}{expected:>10.0f}{uplift:>8.0f}%  {verdict}")

release   7-day incidents  expected   uplift  verdict
R-31                  144       126      14%  normal range
R-32                  164       126      30%  investigate
R-33                  119       126      -6%  normal range
R-34                  138       126      10%  normal range
R-35                  261       126     107%  investigate
R-36                  125       126      -1%  normal range

A simple uplift check like this helps release managers spot releases that disrupted users, even when no single major incident occurred. Larger uplifts trigger a review of what slipped through testing, communication or readiness.

ITIL (Version 5) note

Published summaries of ITIL (Version 5), checked in October 2026, keep release management as a separate practice in the product and service management group. As in ITIL 4, it is distinct from deployment management, which lesson 7 covers.