ITIL 4 Release Management key terms

One or more changes to a service or other configuration item, or a collection of configuration items, made available for use. A release can be a single component or a coordinated bundle delivered together.

The practice of making new and changed services and features available for use. It plans, schedules, and controls the movement of releases through environments to deliver value to customers.

The activity of moving a new or changed configuration item into a live environment, or into a controlled test environment. Deployment is a technical activity that executes what the release plan authorises.

The practice of moving new or changed hardware, software, documentation, processes, or other components to live environments. It focuses on the mechanics of transferring components rather than on making them available to users.

A document that defines the scope, schedule, resources, and approach for delivering one or more releases. It sets expectations for what will be delivered, when, and by whom.

The agreed timeline showing when releases will be delivered, including dates, milestones, and dependencies. It aligns release activity with change, deployment, and business calendars.

A defined period during which a release may be deployed and made live, chosen to minimise business disruption. Windows are agreed with stakeholders and constrain when deployment activity can occur.

The set of configuration items that are released together as a single package. The choice of release unit balances the need for coordination against the risk and complexity of bundling components.

A collection of one or more release units, along with the documentation and instructions needed to deploy and support them. It is the artefact handed to deployment and support teams.

The compiled, assembled, and verified output of the build process for a release, ready for testing or deployment. A build is typically assigned a unique identifier for traceability.

A version of a release that has passed initial testing and is a candidate for final approval and deployment. It is subject to further validation before being declared ready for production.

The state in which a release has met its defined exit criteria, including testing, approvals, and support preparation, so it can proceed to deployment. Readiness is assessed before authorisation.

The formal decision, usually by a change authority, that a release may proceed to deployment. It confirms that risks, testing, and readiness criteria have been reviewed and accepted.

The practice of maximising the number of successful service and product changes by ensuring risks are properly assessed and changes are authorised appropriately. It governs the approval of releases and deployments.

The person or group responsible for authorising a change or release, within limits defined by the organisation. Authority may be delegated based on risk, value, and change type.

A low-risk, pre-authorised change that follows a defined procedure and does not require individual approval each time. Standard changes are often delivered through routine releases.

A change that must be assessed and authorised through the change enablement process before it proceeds. Its risk level determines the authority and rigour applied to its release.

A change that must be introduced as soon as possible, often to resolve an incident or restore service. Emergency releases typically follow an expedited assessment and authorisation route.

A period during which changes and releases are restricted or prohibited, often around peak business times or critical events. Exceptions require explicit authorisation from the relevant change authority.

The practice of ensuring that the configuration items and their relationships are identified, recorded, and maintained accurately. It provides the data that release and deployment activities depend on.

Any component that needs to be managed in order to deliver an IT service, such as hardware, software, documentation, or a service. Its records support release planning and deployment.

A database that stores configuration records and the relationships between configuration items throughout their lifecycle. It is used to track which versions are deployed where and to support release planning.

A recorded and approved version of a configuration item or set of items that serves as a reference point for change. Baselines allow releases to be compared and rolled back to a known state.

A secure, controlled location where the definitive, authorised versions of software and related artefacts are stored. It ensures that only approved versions are used for deployment.

A distinct set of infrastructure and configuration used to run and test services, such as development, test, staging, or production. Releases move through environments in a controlled sequence.

A near-production environment used to validate a release before it goes live. It closely mirrors production so that deployment and integration issues are found before customers are affected.

The live environment where services are delivered to users and customers. Deployment into production is the final step that makes a release available for use.

The process of reverting a release or deployment to a previous known-good state after a problem is detected. It depends on a valid baseline and tested recovery procedures.

A documented set of steps for reversing a release or deployment if it fails or causes unacceptable impact. It defines triggers, actions, and responsibilities for restoring the prior state.

A deployment technique using two identical environments, one live and one idle, so a new release is switched into service with minimal downtime. Rollback is fast because the previous environment remains intact.

A release approach that deploys a new version to a small subset of users or infrastructure first, then expands it if no problems appear. It limits the blast radius of a faulty release.

A release delivered in stages to different user groups or locations over time, rather than all at once. It reduces risk and allows feedback and fixes between phases.

A release in which all components are deployed to all users at the same time. It offers simplicity but carries higher risk because problems affect the whole user base at once.

A practice where developers frequently merge code changes into a shared repository, triggering automated builds and tests. It helps detect integration problems early in the release pipeline.

A practice in which software is kept in a deployable state at all times, with automated testing and release processes. It enables frequent, low-risk releases when the business requires them.

The automated sequence of stages, such as build, test, and deploy, that a release passes through. It provides repeatability, traceability, and control over how releases reach production.

The practice of ensuring that new or changed services meet defined requirements and are fit for use. It provides the evidence that supports release readiness and authorisation decisions.

The practice of maintaining and improving the effective, efficient, and convenient use of information and knowledge. Release documentation and known-error records support support teams after deployment.

A problem that has been analysed and has a documented root cause and workaround. Known errors are relevant to releases because fixes may be included in planned or emergency releases.