Continuous Delivery Architecture flashcards

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

Continuous delivery definition

Practice where every change is automatically built, tested, and kept in a deployable state, with release to production a deliberate business decision rather than a technical hurdle.

Deployment versus release

Deployment installs a version into an environment; release exposes it to users. Separating them enables dark launches, canary exposure, and instant rollback by flag.

Lead time for changes

Elapsed time from code commit to that change running in production. Wait and queue time usually dominate, so reducing batch size and approvals shortens it most.

Flow efficiency

Ratio of active process time to total lead time in a value stream. Values below roughly twenty-five percent indicate large queues and handoff delays.

Change failure rate

Share of deployments that cause degraded service and require remediation such as rollback, hotfix, or incident response. One of the four DORA delivery metrics.

Trunk-based development

All developers commit to one shared branch at least daily, using short-lived branches and feature flags to hide incomplete work, reducing merge conflicts and integration risk.

Build once, deploy many

Build a single immutable artifact per commit and promote that exact binary through every environment, so tested bits are the bits that reach production.

Immutable artifact identity

Artifacts identified by content digest or commit SHA rather than a mutable tag, guaranteeing that what was tested is exactly what is deployed later.

Dependency lockfile

Committed file pinning the exact resolved versions and hashes of transitive dependencies, making builds deterministic and resistant to upstream version drift or tampering.

Reproducible build

A build producing a bit-identical artifact from the same source and inputs, requiring pinned toolchains, digest-pinned base images, and normalized timestamps.

Software bill of materials

Machine-readable inventory of components and versions inside an artifact, typically SPDX or CycloneDX, used for vulnerability response and license compliance.

Semantic versioning rules

MAJOR for incompatible changes, MINOR for backward-compatible features, PATCH for backward-compatible fixes; pre-release identifiers sort before the corresponding release version.

Deployment pipeline definition

Automated sequence of stages from commit to release where each stage is a quality gate and failure halts promotion of the artifact.

Commit stage budget

Target of roughly ten minutes or less for compile, unit tests, and static analysis, keeping feedback fast enough that developers wait for results.

Pipeline as code

Pipeline definition stored in version control alongside the application, making gate logic reviewable, auditable, and reproducible across branches and rebuilds.

Idempotent pipeline step

Step that produces the same result when re-executed, allowing safe automatic retries after transient infrastructure failures without duplicating side effects.

Test pyramid

Guidance favoring many fast unit tests, fewer service and contract tests, and very few slow end-to-end UI tests, keeping pipeline feedback fast and stable.

Consumer-driven contract testing

Consumers publish expected request and response contracts; providers verify them in their own pipeline, catching incompatibilities without deploying both services together.

Flaky test quarantine

Removing intermittently failing tests from the blocking gate, tracking their flake rate, and requiring a fix or deletion before they return.

Test data isolation

Each pipeline run creates its own uniquely named data or tenant, so parallel runs never collide and results stay deterministic and repeatable.

Test double types

Stubs return canned responses, mocks assert interactions, and fakes are lightweight working implementations. Prefer fakes at service boundaries for realistic behavior.

Infrastructure as code drift

Divergence between declared infrastructure definitions and live resources caused by manual console changes, detected by scheduled plan or refresh comparisons.

Remote state with locking

Terraform-style state stored in a shared encrypted backend with a lock, preventing concurrent applies from corrupting the resource mapping.

Ephemeral environments

Short-lived environments created per branch or pull request and destroyed automatically on merge or timeout, giving realistic integration testing without permanent cost.

Environment parity

Keeping operating system, runtime, and configuration mechanism identical across stages, varying only data such as sizes and endpoints, so tests predict production behavior.

Blue-green deployment

Two identical environments where traffic switches from old to new at the router; rollback is switching back, and both versions must share a compatible schema.

Canary release

Routing a small traffic percentage to the new version, comparing error rate and latency against baseline, then ramping or aborting automatically.

Feature flag decoupling

Runtime toggle that separates deployment from release, letting code ship dark and enabling instant disable; each flag needs an owner and expiry.

Expand-and-contract migration

Schema change pattern: add new structures and dual-write, backfill and verify, switch reads, then remove old structures in a later release to keep versions compatible.

Configuration externalization

Keeping environment-specific settings outside the artifact and injecting them at runtime, so one immutable binary runs unchanged across all stages.

Secret rotation on leak

When a credential is exposed, revoke and rotate it first, then purge history and audit usage; rotating before cleanup limits the exposure window.

Error budget

One minus the service level objective, expressed as allowed unreliability over the window; burning it fast should slow releases and trigger investigation.