Deployment management concepts and scope
Domain 1: Deployment management concepts and scope
This domain tests whether you can separate deployment from release and change enablement, state the practice purpose accurately, and define scope. Expect questions on deployment units, environments, and what counts as a deployment.
Core rules
- ITIL 4 purpose: make new or changed hardware, software, documentation, processes, or other components available for use in the live environment.
- Deployment is movement into live; release is making a service or feature available to users. One release can require several deployments; one deployment can occur without a user-facing release, such as a database schema change.
- Change enablement authorizes and schedules changes; deployment executes the movement. Standard changes can be pre-authorized, so not every deployment needs a new change request.
- Scope covers service components and configuration items, not only application code. Documentation, scripts, infrastructure definitions, and data migrations can be deployed.
- Environments such as build, test, staging, and production are part of deployment planning; promotion paths and entry and exit criteria must be defined.
Worked example
A team deploys a new checkout API behind a feature flag. The code is deployed to production, but the feature is not released to customers until the flag is enabled. The deployment moved the artifact; release management controlled availability; change enablement authorized the standard change. The exam may ask what was deployed: the API component, not the customer-facing feature.
Traps
- Calling every deployment a release.
- Assuming deployment management authorizes change.
- Ignoring non-code components such as documentation or configuration.
- Treating production as the only environment that matters.