Release Management
Release Management is the ITIL 4 practice whose purpose is to make new and changed services and features available for use. The exam tests your ability to separate release from deployment, select and justify release models, define release units and policy, and show how release work integrates with change enablement, deployment, testing, and configuration management.
Core rules and concepts
- Release vs deployment: deployment moves components into a live environment; release makes them available to users. A release can occur without a new deployment (for example, enabling a feature flag).
- Release unit: the set of components released together, defined by business or customer value, not by team or technology boundaries.
- Release models: big bang (all at once), phased (by location, group, or service), pull (users choose when), and continuous delivery (small, frequent releases).
- Release policy: sets frequency, roles, acceptance criteria, versioning, and rollback expectations. The release plan adds scope, schedule, risk, communications, and backout.
- Techniques: CI/CD pipelines, version control, feature flags, canary releases, and blue-green deployment reduce risk by shrinking blast radius.
- Interfaces: change enablement authorizes change; deployment management executes movement; service validation and testing provides evidence; service configuration management records versions.
Worked example
A retailer releases a new checkout feature. The team deploys code behind a feature flag using blue-green deployment, then releases to 5% of customers, monitors error rates, and expands to 25%, 50%, and 100%. Reasoning: the release unit is the checkout service plus its dependent payment configuration; phased release limits impact; the rollback trigger is an error rate above 2% for 15 minutes; change enablement authorizes the change, while deployment moves the code. Release is complete only when the feature is available to the intended users.
Traps
- Using “release” and “deployment” interchangeably.
- Defining release units by team structure rather than customer value.
- Omitting rollback or backout criteria from the release plan.
- Treating a feature flag as a deployment activity; it controls availability, not code movement.
- Assuming release management authorizes change; that is change enablement’s role.