Continuous Delivery Architecture key terms

The end-to-end sequence of activities, from a customer request to delivered value, including both value-adding and waiting steps. Mapping it exposes handoffs, queues, and delays that inflate lead time.

The elapsed time from a change being committed or requested until it runs in production. It is the headline delivery metric, dominated by queueing and waiting rather than actual work time.

The time taken to complete one unit of work once it has started, measured from work start to done. Teams use it to spot bottlenecks inside a stage rather than across the whole value stream.

The ratio of time spent actively working on an item to its total elapsed time in the value stream. Low percentages reveal that most delay comes from waiting, not from doing the work.

A cap on how many items may be in a stage at once. It shortens queues, exposes bottlenecks, and reduces context switching, which in turn lowers lead time and improves predictability.

An automated, staged path a change travels through, from commit to production, with each stage verifying the build and gating promotion. It makes the release process repeatable, visible, and fast.

How often an organization releases changes to production. High frequency signals small batch sizes, automated verification, and low release risk, and it correlates with faster recovery from failures.

The proportion of production changes that cause degradation and require remediation such as a rollback or hotfix. It measures release quality and pairs with deployment frequency as a delivery outcome metric.

A branching model where developers integrate small changes into a shared mainline at least daily, using short-lived branches. It minimizes merge pain and keeps the pipeline continuously releasable.

The immutable output of a build, such as a container image or versioned package, that is promoted unchanged through environments. Storing it in a registry lets every stage test the exact same bytes.

A versioned store for build outputs and dependencies, such as a package registry or container registry, with retention and access control. It is the single source of truth for what gets deployed.

A build output that is never modified after creation; any change produces a new version with a new identifier. Immutability guarantees that what was tested is exactly what is deployed.

A file recording the exact resolved versions and checksums of every transitive dependency. Committing it makes builds reproducible and prevents silent upgrades from breaking a previously working release.

A build that produces bit-identical output from the same source and inputs, regardless of when or where it runs. It supports verification, auditing, and trust in the supply chain.

A machine-readable inventory of components and their versions inside a build, including transitive libraries. It enables rapid impact analysis when a vulnerability is disclosed in a dependency.

Automated inspection of dependencies, images, and infrastructure definitions for known security flaws. Running it in the pipeline fails builds that introduce risky components before they reach production.

A discrete phase in a deployment pipeline, such as build, test, or deploy, with defined entry criteria and outcomes. Stages run in order and stop promotion when their checks fail.

An automated condition that must pass before a change advances, such as test coverage thresholds or security findings. Gates encode policy as code so promotion decisions are consistent and auditable.

Running independent jobs, such as test shards or environment provisioning, concurrently within a pipeline. It reduces feedback time, which keeps developers engaged and shortens the overall lead time.

Defining pipeline structure, stages, and triggers in version-controlled files rather than through a UI. It makes the delivery process reviewable, reusable, and consistent across repositories.

A testing heuristic favoring many fast unit tests, fewer integration tests, and a small number of slow end-to-end tests. It balances confidence against feedback speed and maintenance cost.

A test verifying that a service's requests and responses match what its consumers expect. It catches integration breakage without spinning up every dependent system in an end-to-end run.

A stand-in for a real dependency, such as a stub, fake, or mock, used to isolate the code under test. Doubles keep tests fast and deterministic but can drift from real behavior.

A test that passes and fails on unchanged code, usually due to timing, shared state, or ordering. Flaky tests erode trust in the pipeline and are often quarantined until fixed.

A fast, shallow check that a deployed system starts and its critical paths respond. It is run immediately after deployment to catch gross failures before deeper verification.

Managing servers, networks, and platform resources through versioned definition files applied by tooling. It makes environments reproducible, reviewable, and consistent across stages.

A provisioning approach where servers or containers are replaced rather than patched in place. Each deploy builds a fresh instance from a known image, eliminating configuration drift.

Keeping development, test, staging, and production environments as similar as possible in configuration and dependencies. Parity reduces the class of defects that only appear after promotion.

The gradual divergence of a live environment from its declared or expected state due to manual changes. Detecting drift through periodic reconciliation keeps infrastructure trustworthy and reproducible.

Running two identical environments and switching traffic from the live one to the newly deployed one. It makes releases near-instant and rollback a simple traffic switch back.

Routing a small share of traffic to a new version while monitoring error rates and latency before widening exposure. It limits blast radius and gives real-user evidence for promotion decisions.

A runtime switch that enables or disables functionality without redeploying code. Flags decouple release from deployment, support gradual rollout, and allow instant disabling of a faulty feature.

Reverting production to a previous known-good version or state after a failed change. Fast, tested rollback lowers the cost of failure and encourages smaller, more frequent releases.

A schema change technique that first adds backward-compatible structures, migrates data and code, then removes old structures. It lets application and database changes deploy independently without downtime.

A database modification that older application versions can still tolerate, such as adding a nullable column. It is required for zero-downtime deploys where old and new code run simultaneously.

Storing, distributing, and rotating credentials through a dedicated vault or secrets service rather than in code or images. It limits exposure and supports short-lived, auditable access.

Automated detection of credentials accidentally committed to source code or build logs. Running it pre-merge and on history prevents leaks that would otherwise require immediate rotation.

The ability to understand a system's internal state from its outputs, primarily logs, metrics, and traces. It lets teams diagnose production issues quickly instead of guessing from symptoms.

Recording a request's path across services with a shared trace identifier and per-span timings. It pinpoints which service or dependency causes latency in a distributed deployment.

A target reliability level for a service, expressed as a measurable ratio such as successful requests over total. It gives release decisions an objective basis and bounds error budgets.