Glossary

Artifact

A build artifact is the immutable, packaged output of a build step - a container image, a JAR, a wheel, a zip, or a signed binary - that later pipeline stages deploy without rebuilding. Artifacts are versioned and stored in a registry (OCI registry, npm, Maven, PyPI) so the exact bits tested are the exact bits released. Treating the artifact as immutable is what makes "build once, deploy many" possible.

Artifact Registry

An artifact registry is a versioned store for build outputs such as container images, language packages, and Helm charts, addressed by name and tag or by content digest. Examples include Docker Hub, GitHub Container Registry, Amazon ECR, and JFrog Artifactory. Pulling by immutable digest rather than a mutable tag guarantees the deployed bytes match what was tested.

Blue-Green Deployment

Blue-green deployment runs two identical production environments, "blue" (live) and "green" (idle), and cuts traffic over to the new version by switching a router or load balancer. Because the old environment stays warm, rollback is an instant traffic switch back to blue. The trade-off is roughly double the infrastructure during the cutover window.

Canary Deployment

A canary deployment releases a new version to a small fraction of traffic or users first, observes error rate and latency against the baseline, and then progressively shifts more traffic if the signals stay healthy. It limits the blast radius of a bad release and enables automatic rollback on a regression. It requires good metrics and a traffic-splitting layer (service mesh, ingress, or feature flag).

CI (Continuous Integration)

Continuous Integration is the practice of merging every developer's work into a shared mainline frequently - ideally many times a day - with each merge verified by an automated build and test run. Its goal is to surface integration conflicts and broken builds within minutes rather than at a painful end-of-cycle merge. A green mainline is the contract CI enforces.

CD (Continuous Delivery)

Continuous Delivery extends CI so that every change that passes the pipeline is always in a deployable state, releasable to production at the push of a button. The release decision stays manual, but the mechanics are fully automated and rehearsed. It should not be confused with Continuous Deployment, where the push is automatic too.

Continuous Deployment

Continuous Deployment automatically releases every change that passes the full pipeline to production, with no manual gate. It demands a high-confidence test suite, progressive delivery (canary or blue-green), and fast automated rollback, because there is no human in the loop to catch a bad change. It is the most automated point on the CI/CD spectrum.

Pipeline

A pipeline is the automated sequence of stages a change passes through - typically build, test, scan, package, and deploy - defined as code in a file such as .github/workflows/ci.yml, .gitlab-ci.yml, or a Jenkinsfile. Stages run in order, often with parallel jobs inside a stage, and a failure short-circuits the rest. The pipeline definition lives in the repository so it is versioned alongside the code it builds.

Stage

A stage is a logical phase of a pipeline that groups related jobs, such as a "test" stage or a "deploy" stage, and usually acts as a gate: the next stage starts only when the current one succeeds. Stages give a pipeline its top-level shape and define where approvals and fan-out happen. Jobs within a stage commonly run in parallel.

Job

A job is a unit of work in a pipeline that runs on a single runner or agent, made up of an ordered list of steps sharing one workspace and environment. Jobs within a stage can run in parallel; jobs across stages run in sequence. A failed job typically fails its stage unless explicitly allowed to fail.

Runner

A runner (or agent, or executor) is the machine or container that actually executes a pipeline job. Runners may be hosted by the CI provider (GitHub-hosted runners) or self-hosted on your own infrastructure for custom hardware, private network access, or cost control. Ephemeral runners that are destroyed after each job reduce state leakage between builds.

Build Cache

A build cache stores intermediate build outputs and downloaded dependencies between pipeline runs so unchanged work is not repeated, dramatically cutting build time. Caches are keyed on a hash of inputs (lockfile, source) and must be invalidated when those inputs change. A poorly keyed cache that goes stale is a classic source of "works on my machine" pipeline bugs.

GitOps

GitOps is an operating model in which the desired state of infrastructure and applications is declared in Git, and an in-cluster agent (such as Argo CD or Flux) continuously reconciles the live system to match. Git becomes the single source of truth and the audit log; deployments happen by merging a commit, and drift is automatically detected and corrected. It pairs naturally with Kubernetes and declarative manifests.

Infrastructure as Code (IaC)

Infrastructure as Code manages servers, networks, and cloud resources through machine-readable definition files (Terraform, Pulumi, CloudFormation, Ansible) kept under version control, rather than manual console clicks. It makes environments reproducible, reviewable, and rebuildable, and it turns infrastructure changes into pull requests. The same plan-then-apply discipline used for code applies to infrastructure.

Idempotency

An operation is idempotent if applying it multiple times produces the same end state as applying it once. Idempotency is central to IaC apply, configuration management, and deploy scripts, because reruns after a partial failure must converge rather than duplicate resources. Declarative tools achieve it by reconciling toward a desired state instead of issuing imperative create commands.

Declarative Configuration

Declarative configuration describes the desired end state of a system ("there should be three replicas of this service") and lets a controller figure out the steps to reach it, in contrast to imperative scripts that spell out each command. It is naturally idempotent and self-healing because the controller continuously reconciles actual state to desired state. Kubernetes manifests and Terraform configurations are declarative.

Drift

Configuration drift is the divergence between the state declared in code and the actual state of the running system, caused by manual changes, failed applies, or out-of-band tooling. Drift undermines reproducibility and is a common cause of "it worked in staging" failures. GitOps controllers and terraform plan detect drift; reconciliation corrects it.

Container

A container is a lightweight, isolated unit that packages an application with its dependencies and runs as a process on a shared host kernel, using namespaces and cgroups for isolation. Unlike a virtual machine it does not bundle a full guest OS, so it starts in milliseconds and is dense to pack. The OCI standard defines the image and runtime formats containers use.

Container Image

A container image is an immutable, layered filesystem snapshot plus metadata (entrypoint, environment, exposed ports) from which containers are instantiated. Images are built from a Dockerfile, identified by a content-addressable digest, and tagged for human reference. Smaller, minimal base images (distroless, Alpine) reduce attack surface and pull time.

Dockerfile

A Dockerfile is the declarative recipe for building a container image, a sequence of instructions (FROM, RUN, COPY, CMD) each of which creates a cached layer. Ordering instructions from least to most frequently changing maximizes layer-cache reuse and speeds rebuilds. Multi-stage builds keep build tools out of the final runtime image.

Multi-Stage Build

A multi-stage build uses several FROM stages in one Dockerfile, compiling or assembling in an early stage and copying only the finished artifacts into a slim final stage. The result is a small runtime image free of compilers, build caches, and secrets. It is the standard technique for shrinking images and reducing attack surface.

Orchestration

Orchestration is the automated scheduling, scaling, networking, and lifecycle management of containers across a cluster of machines, provided by systems such as Kubernetes or Nomad. The orchestrator places workloads, restarts failed containers, rolls out new versions, and maintains the declared replica count. It turns a fleet of hosts into a single logical compute pool.

Kubernetes

Kubernetes is an open-source container orchestrator that runs declarative workloads across a cluster, reconciling actual state to the desired state defined in manifests. Core objects include Pods, Deployments, Services, and ConfigMaps, managed by controllers via the API server. It is the de facto platform for cloud-native deployment and the substrate most GitOps and progressive-delivery tooling targets.

Helm

Helm is a package manager for Kubernetes that bundles related manifests into a versioned, parameterizable unit called a chart, rendered with user-supplied values at install time. It enables reuse, templating, and rollbacks of application deployments. Helm releases are tracked so helm rollback can revert to a previous revision.

Rollback

A rollback returns a system to a known-good previous version after a bad release, ideally as a fast, rehearsed, automated action rather than an emergency. Strategies include re-deploying the previous immutable artifact, switching traffic back in blue-green, or reverting a GitOps commit. Database migrations complicate rollback, which is why backward-compatible, expand-then-contract schema changes are preferred.

Feature Flag

A feature flag (toggle) is a runtime switch that turns a code path on or off without a redeploy, decoupling the act of deploying code from the act of releasing a feature. Flags enable dark launches, canary by user segment, and instant kill switches for a misbehaving feature. Stale flags accumulate as technical debt and should be removed once a rollout completes.

Trunk-Based Development

Trunk-based development is a branching model where developers integrate small changes into a single shared branch (trunk) at least daily, behind feature flags when work is incomplete. It keeps merges tiny and continuous, which is what makes true CI possible, and avoids the painful long-lived feature branches and merge hell of heavier flows. It pairs with feature flags to hide unfinished work.

SLI (Service Level Indicator)

A Service Level Indicator is a quantitative measure of a service's behaviour as experienced by users, such as request latency, error rate, or availability. SLIs are the raw signals from which SLOs are set and error budgets computed. A good SLI is a ratio of good events to valid events that correlates with user happiness.

SLO (Service Level Objective)

A Service Level Objective is a target value or range for an SLI over a time window, for example "99.9% of requests succeed over 30 days". SLOs make reliability a measurable engineering goal and define when to slow feature work in favour of stability. They are internal targets, typically stricter than any externally promised SLA.

Error Budget

An error budget is the amount of unreliability an SLO permits - the complement of the objective, so a 99.9% availability SLO allows 0.1% errors. As long as the budget is unspent, the team can ship aggressively; once it is exhausted, the policy shifts priority to reliability work. It turns the tension between velocity and stability into an objective number.

Observability

Observability is the property of a system that lets you understand its internal state from its external outputs, classically via metrics, logs, and traces (the "three pillars"). Unlike basic monitoring of known failure modes, observability aims to let you ask new questions about unforeseen problems without shipping new code. It is the prerequisite for safe progressive delivery and fast incident diagnosis.

Monitoring

Monitoring is the continuous collection and alerting on predefined signals - CPU, memory, request rate, error rate - to detect known failure conditions. It answers "is the system healthy against the things we already know to watch?", whereas observability extends to investigating unknowns. Prometheus and Grafana are a common open-source monitoring stack.

Metrics

Metrics are numeric measurements sampled over time, such as counters, gauges, and histograms, cheap to store and ideal for dashboards, trends, and alerting. They aggregate well but lose per-request detail, which is why they pair with traces and logs. The RED method (Rate, Errors, Duration) and USE method (Utilization, Saturation, Errors) are common metric frameworks.

Distributed Tracing

Distributed tracing follows a single request as it propagates across services, recording timed spans linked by a shared trace ID to reveal where latency and errors accumulate. It is essential for debugging microservices where a single user action fans out to many backends. OpenTelemetry is the vendor-neutral standard for instrumenting traces, metrics, and logs.

Secrets Management

Secrets management is the secure storage, distribution, rotation, and auditing of credentials such as API keys, tokens, and database passwords, using a dedicated system (HashiCorp Vault, AWS Secrets Manager, sealed secrets) instead of plaintext in code or environment files. Secrets should be injected at runtime, never committed to Git, and rotated regularly. A leaked secret in pipeline logs is a frequent and avoidable incident.

Shift Left

Shifting left means moving quality and security activities - testing, linting, dependency scanning, secrets detection - earlier in the development lifecycle, ideally to the developer's machine and the pull request, rather than late in a release. Catching defects earlier is dramatically cheaper than catching them in production. It is a guiding principle of DevSecOps.

DevSecOps

DevSecOps integrates security practices into the DevOps pipeline so that security is a shared, automated, continuous responsibility rather than a gate at the end. It embeds SAST, DAST, dependency scanning, IaC scanning, and policy checks into CI/CD. The aim is to make the secure path the easy, default path for developers.

SAST (Static Application Security Testing)

Static Application Security Testing analyzes source code or binaries without executing them to find vulnerability patterns such as injection flaws, insecure deserialization, and hardcoded secrets. It runs early (in the IDE or on every pull request) and scales to every commit, but produces false positives and cannot find runtime-only issues. It complements DAST, which tests the running application.

DAST (Dynamic Application Security Testing)

Dynamic Application Security Testing probes a running application from the outside, sending crafted inputs to find vulnerabilities that only appear at runtime, such as authentication flaws and server misconfigurations. It has few false positives but runs later and covers only exercised paths. It complements SAST, which inspects code statically.

SBOM (Software Bill of Materials)

A Software Bill of Materials is a formal, machine-readable inventory of every component and dependency in a piece of software, including versions and licenses, expressed in a standard format such as SPDX or CycloneDX. It enables rapid impact assessment when a vulnerability like Log4Shell emerges, and it underpins supply-chain security and compliance. Generating an SBOM per build is increasingly required by regulation.

Supply Chain Security

Software supply chain security protects the integrity of everything that goes into a release - dependencies, build systems, and artifacts - against tampering, typosquatting, and compromised toolchains. Practices include pinning dependencies by hash, generating SBOMs, signing artifacts (Sigstore/cosign), and attesting build provenance (SLSA). The xz and SolarWinds incidents made it a board-level concern.

DORA Metrics

DORA metrics are four research-backed measures of software delivery performance from the DevOps Research and Assessment program: deployment frequency, lead time for changes, change failure rate, and time to restore service. The first two gauge throughput; the last two gauge stability, and elite teams excel at both simultaneously. They are the standard yardstick for assessing DevOps capability.

Lead Time for Changes

Lead time for changes, one of the four DORA metrics, measures the time from a code change being committed to it running in production. Short lead time reflects a fast, automated, low-friction pipeline and small batch sizes. It is a throughput metric, paired with deployment frequency and balanced against the stability metrics.

Mean Time to Recovery (MTTR)

Mean Time to Recovery (or Restore) measures how long it takes to restore service after a failure in production. A low MTTR - enabled by good observability, fast rollback, and rehearsed incident response - matters more for user-perceived reliability than trying to never fail at all. It is one of the two DORA stability metrics, alongside change failure rate.

Change Failure Rate

Change failure rate, a DORA stability metric, is the proportion of deployments to production that cause a failure requiring remediation such as a rollback, hotfix, or patch. Lower is better; elite teams keep it low while still deploying frequently, proving speed and stability are not opposed. It is read together with MTTR to judge release safety.

Immutable Infrastructure

Immutable infrastructure treats servers and images as never-modified-in-place: to change a running system you build a new image and replace instances rather than patching live hosts. This eliminates configuration drift and snowflake servers, and makes rollback a redeploy of the previous image. It is enabled by IaC and container images and underpins reliable, repeatable deployments.

Smoke Test

A smoke test is a small, fast suite that verifies the most critical paths of a freshly deployed build are working - does the service start, answer health checks, and serve a key endpoint - before promoting it further. It is the quick "is it on fire?" check after a deploy, distinct from full regression testing. Failing smoke tests should automatically halt or roll back a rollout.

Health Check

A health check is an endpoint or probe the platform polls to decide whether an instance is alive and ready to receive traffic. Kubernetes distinguishes a liveness probe (restart if unhealthy) from a readiness probe (remove from load balancing until ready) and a startup probe (allow slow boots). Accurate health checks are essential for zero-downtime deployments and self-healing.

Zero-Downtime Deployment

Zero-downtime deployment releases a new version without interrupting service, by bringing new instances up and draining old ones only after they are healthy and serving. Techniques include rolling updates, blue-green, and canary, all relying on accurate readiness checks and connection draining. Backward-compatible database changes are required so old and new versions can run concurrently during the rollover.