ITIL 4 Deployment Management key terms

The activity of moving a new or changed service component, or a group of components, into the live environment where it can be used. It transfers, installs, configures and verifies the item so that it works as intended.

The ITIL 4 practice that makes new or changed services and service components available for use. It covers planning, scheduling, building, testing, transferring, verifying and handing over components into the live environment.

One or more changes to a service or service component, or a group of related components, that are built, tested and made available together. A release may be deployed in one or several separate deployment events.

The ITIL 4 practice that plans and controls the building, testing and delivery of services and components across environments. It decides what constitutes a release and coordinates the schedule with deployment management.

The set of service components that is versioned, tested and released together as a single logical package. Its boundaries shape how much must be deployed at once and how rollback can be scoped.

The smallest set of components that can be deployed independently in a given environment. It is defined by technical dependencies and by the packaging decisions made during deployment planning.

A documented description of how, when and by whom a deployment will be carried out. It covers scope, sequence, dependencies, resources, timing, verification steps, communication and rollback arrangements.

The agreed timetable of deployment activities and their dependencies, including windows, approvals and freeze periods. It is coordinated with change, release and capacity plans so that clashes and peaks are avoided.

The agreed period during which a deployment may be performed, often chosen to limit impact on users. It includes time for preparation, execution, verification and, where needed, recovery before normal service resumes.

The automated sequence of build, test and promotion steps that moves a component through environments toward production. It provides repeatability, traceability and fast feedback on the quality of each change.

The use of tools and scripts to perform deployment steps with minimal manual intervention. It reduces variation and error, speeds up repeated deployments and produces consistent, auditable records of what was executed.

A working approach in which code changes are merged and tested frequently, and artifacts are kept in a state that can be deployed at any time. It relies on automation and strong deployment management controls.

A set of infrastructure, software and configuration used for a defined purpose, such as development, testing, staging or production. Deployment management controls the promotion of components between these environments.

The environment in which services are delivered to real users and customers under agreed service levels. Deployment into it requires the strongest controls, verification and readiness checks.

Any part of a service that is managed and can be deployed, such as application code, a configuration file, middleware, a database change or infrastructure. Components are the units that deployment activities move and verify.

Any element that must be managed in order to deliver a service, recorded with its attributes and relationships. Deployment management relies on accurate records of configuration items to know what is where and how it depends on others.

The practice of maintaining accurate information about configuration items and their relationships throughout their lifecycle. It gives deployment teams a reliable baseline of what exists in each environment before and after a change.

A repository holding records of configuration items and the relationships between them. Deployment activities update it so that the recorded state of each environment matches reality after every deployment.

The documented evidence of a deployment, including what was deployed, where, when, by whom, the outcome and any deviations. It supports audit, troubleshooting, rollback decisions and continual improvement.

Restoring a component or environment to its previous known-good state after a deployment fails or causes harm. It requires a tested method, available backups or previous versions, and a clear decision point.

A documented procedure describing how to reverse a deployment, who authorizes it and how long it takes. It is prepared before deployment and validated in test environments wherever practical.

Removing or disabling a deployed change without necessarily restoring the prior version, for example by switching off a feature. It is a recovery option distinct from a full rollback to previous components.

A configuration mechanism that enables or disables functionality at runtime without redeploying code. It allows deployment to occur separately from release, reducing risk and supporting gradual exposure to users.

A technique that deploys a change to a small subset of users or infrastructure first, then expands it if results are good. It limits blast radius and gives real-world evidence before full rollout.

A technique using two parallel environments, where traffic is switched from the current one to the updated one. It shortens cutover time and makes reverting to the previous environment straightforward.

The state of being prepared for live operation, covering technical configuration, monitoring, support arrangements, documentation, training and acceptance by the receiving teams. Deployment should not proceed until readiness is confirmed.

The practice that provides objective evidence that a service or component meets agreed requirements and is fit for use. Deployment depends on its results to confirm that what is being transferred is acceptable.

The transfer of responsibility for a deployed component to the team that will operate and support it. It includes documentation, access, known issues, monitoring and confirmation that the receiver accepts ownership.

The ITIL 4 practice that maximizes successful changes by assessing risk, authorizing work and scheduling it. Deployment management executes authorized changes and feeds outcomes back to it.

A low-risk, pre-authorized change with a documented procedure and defined trigger. Such changes are often deployed through automated pipelines with minimal per-instance approval.

A change that must be assessed and authorized according to its risk and impact before deployment. Its deployment is usually scheduled and may require coordination with release and change calendars.

A change that must be introduced as soon as possible, often to restore or protect service. Deployment follows an expedited but still recorded path, with retrospective review afterwards.

The role accountable for planning, coordinating and controlling deployments across environments. The person ensures readiness, authorizes execution within delegated limits and confirms outcomes are recorded.

The role responsible for planning releases and deciding their content, timing and packaging. This role works closely with deployment management to ensure releases can be deployed safely and predictably.

The group that performs deployment activities such as transferring, installing, configuring and verifying components. Its skills span platform, automation, database and application knowledge, and it works closely with operations and development.

The point of contact between the service provider and users, handling incidents and requests. It needs advance notice of deployments, known errors and rollback outcomes to support users effectively.

The series of steps an organization uses to create and deliver value to customers. Deployment is a step within the service value stream, and mapping it reveals delays, handoffs and waste.

A technique for visualizing the flow of work through a value stream, including wait times, handoffs and rework. It is used to find deployment bottlenecks and target improvement effort.

The elapsed time from a request or commitment to its delivery into the live environment. Shortening it through better deployment flow is a common objective for continual improvement.

A metric counting how often deployments into a given environment occur over a period. It indicates flow and batch size but must be read alongside failure and recovery measures.

The proportion of deployments that complete without requiring rollback, hotfix or emergency remediation. It reflects the quality of planning, testing and automation and is a useful outcome measure.

The percentage of changes that result in degraded service and require remediation such as rollback or hotfix. It complements deployment success rate by focusing on the harm caused rather than the deployment event.

The average time taken to restore service after an interruption, including interruptions caused by deployment. It measures recovery capability and the effectiveness of rollback and support arrangements.