ITIL 4 Release Management flashcards

33 cards. Read the term and the definition here. The deck at the top of this page is optional.

Release management definition

The ITIL 4 practice that makes new and changed services and features available for use, ensuring they meet agreed acceptance criteria and are safe to operate in the live environment.

Deployment vs release

Deployment moves and installs components into an environment; release makes functionality available to users. A release can occur without a full deployment, for example by enabling a feature flag.

Phased release

A release type in which functionality is delivered to a defined subset of users or locations first, then expanded in stages after validation, reducing the blast radius of failure.

Continuous delivery release

A release type in which small increments are delivered frequently, often automatically, with functionality controlled by feature flags to decouple deployment from user availability.

Big bang release

A release type in which all components are made available to all users at once; highest coordination and rollback risk, used when partial availability is technically or commercially unworkable.

Release unit

The set of components that are released together as one package; its granularity balances change frequency, failure impact, and packaging and testing cost.

Release policy

A documented set of rules governing release types, approval authorities, frequency, naming and versioning, acceptance criteria, and rollback expectations across the organization.

Release plan contents

The scope, schedule, resources, dependencies, risks, acceptance criteria, communication, and rollback approach for a specific release, agreed with stakeholders before build begins.

Release acceptance criteria

Pre-agreed, testable conditions that a release must satisfy, covering functional and non-functional requirements, before it may be made available to users.

Release closure

The final release activity: confirming acceptance, updating records and configuration data, communicating completion, and capturing lessons learned for future releases.

Rollback plan

A verified procedure to restore the previous known-good state if a release fails acceptance or causes unacceptable impact, including triggers, steps, and maximum tolerable downtime.

Feature flag

A configuration toggle that enables or disables functionality at runtime, allowing deployment without immediate release and supporting phased or continuous delivery release types.

Release record

A documented entry identifying the release, its version, contents, schedule, approval, acceptance results, and deployment status, used for audit and configuration accuracy.

Version identification

A consistent naming and numbering scheme applied to releases and their components so that the exact state of the live environment can be traced and reproduced.

Change enablement link

Releases are authorized through change enablement; the change authority assesses risk and approves, while release management executes and confirms the release outcome.

Service validation and testing

The practice that verifies a release meets requirements through functional, non-functional, and user acceptance testing before release management makes it available.

Release risk assessment

Evaluation of likelihood and impact of release failure, considering user reach, criticality, reversibility, and dependencies, which determines release type and approval level.

Canary release

A phased approach in which a release is exposed to a small, monitored user group first; success metrics gate expansion, and failure triggers rollback for that group only.

Blue-green release

A technique using two identical environments where the new version is deployed to the idle environment and traffic is switched after validation, enabling fast rollback.

Release calendar

A schedule of planned releases and freezes, shared with stakeholders so that changes, deployments, and business events are coordinated and do not conflict.

Change freeze

A defined period during which releases are restricted, typically around peak business events, to protect stability; exceptions require explicit authorization by the change authority.

Release communication

Planned messaging to users, support, and operations covering what changes, when, expected impact, known issues, and how to report problems or request rollback.

Post-implementation review

A review after release closure comparing actual outcomes with planned objectives, checking incidents, performance, and user feedback, and recording improvements for future releases.

Emergency release

An expedited release addressing a critical incident or security vulnerability, using a pre-agreed fast-path approval and testing proportionate to urgency while retaining rollback capability.

Release and deployment management

ITIL v3 combined both practices; ITIL 4 separates them, with release management owning availability to users and deployment management owning component transfer and installation.

CMDB update at release

Configuration records for released components must be updated at closure so the configuration management database reflects the actual live state and supports future impact analysis.

Release stakeholder sign-off

Formal confirmation by the service owner and business representative that acceptance criteria are met; sign-off authorizes the release to proceed to availability.

Pilot release

A release made available to a limited, representative user group to validate behavior in a real environment before wider availability; results inform the go or no-go decision.

Release dependency mapping

Identifying components and services that a release depends on or affects, so that sequencing, testing scope, and rollback impact are correctly understood before authorization.

Backout versus rollback

Rollback restores the prior state after a release is made available; backout removes the deployed components. Both must be designed, tested, and time-bounded before release approval.

Release metrics

Measures such as release success rate, failed releases requiring rollback, release cycle time, and change-related incidents, used to evaluate and improve the release management practice.

Release authorization

The decision, made by the authorized change authority using release and change information, that a release may proceed; it is recorded and precedes the release being made available.

Release and support alignment

Support teams must receive release notes, known errors, and training before availability, so incidents can be resolved and users supported from the moment of release.