- Deployment strategies
Big bang deployment
A big bang deployment ships an entire new version at once. Every instance switches over in a single cutover step, with no phased ramp, no parallel environment and no canary slice. It is the simplest deployment shape and the riskiest, because the whole user base sees the change at the same moment.
- Reliability practices
Blameless postmortem
A blameless postmortem is a structured review after an incident that focuses on the systems, tools and decisions that let a failure happen, not on the individual who pushed the button. Teams write a timeline, root cause, contributing factors and concrete action items, so the same class of outage becomes harder to repeat.
- Release safety
Blast radius
Blast radius is the maximum damage a single change, incident or misconfiguration can inflict before it is contained: how many users, services, environments or accounts are exposed. Deployment strategies like canaries, blue-green environments and progressive rollouts exist to shrink that radius so a bad release hurts a slice, not everyone.
- Release engineering
Conventional commits
Conventional commits is a lightweight convention for commit messages that machines can parse. Each message starts with a type (feat, fix, chore), an optional scope in parentheses, and a short imperative subject. Tools use those types to automate version bumps, generate changelogs, and decide when a release pipeline should run.
- Release management
Cutover
A cutover is the moment a system stops running its old version and starts running the new one. In a deployment context, it names the single atomic step - flipping a load balancer, swapping a DNS record, or promoting a route - that makes the new version live for every user, and after which rollback means reversing that step rather than redeploying.
- Release management
Code freeze
A code freeze is a scheduled period, usually just before a release, during which merges into the release branch are restricted to critical bug fixes only. New features are held back so QA, hardening and release preparation can catch up, giving the team a clean, testable candidate to ship.
- Observability practices
Deployment marker
A deployment marker is a timestamped annotation posted to a monitoring, logging or APM system every time a new version ships, so charts, alerts and incident reviews can visually correlate a metric change with the exact release that caused it. Most pipelines emit it as a small HTTP call right after a successful deploy.
- Deployment strategies
Deployment ring
A deployment ring is a release strategy that ships a new version to progressively wider, named cohorts of users - typically an internal ring first, then a beta ring, then general availability - promoting between rings only after each cohort's health signals stay clean, so problems surface in a small audience before reaching everyone.
- Release management
Dark launch
A dark launch ships new code to production but keeps the change hidden from users. The code runs in the live environment - often exercised by silent backend calls or an internal cohort - so teams can measure performance, correctness and capacity under real production traffic before ever exposing the feature to customers.
- Environments
Environment parity
Environment parity is the practice of keeping development, staging and production environments as similar as possible: same operating system, same runtime version, same dependencies, same backing service types and data shape, so a change verified in one environment behaves the same way in the next. It is one of the twelve-factor principles.
- Delivery pipelines
Environment promotion
Environment promotion moves a single built artifact through a chain of runtime environments - typically dev, staging and production - running the same tests and health checks at each stop. The artifact is not rebuilt between environments; only its target changes, so what you tested is exactly what ships.
- Delivery metrics
Error budget
An error budget is the amount of unreliability a service is allowed over a fixed window: the gap between its target reliability (SLO) and 100%. Teams spend that budget on new releases and risky changes; when it runs out, they pause launches and prioritize stability until the window refills.
- Reliability
Failover
Failover is the automatic switch of live traffic from a failing primary system to a healthy standby so users keep being served during an outage. It relies on continuous health checks, a routing layer that can redirect quickly, and a standby kept warm enough to absorb the diverted load.
- Testing
Flaky test
A flaky test passes and fails on the same code without any change, because the outcome depends on timing, environment, or shared state rather than the code under test. Flakies erode trust in CI, hide real regressions behind noise, and slow every pipeline that has to rerun them, so fixing or quarantining them is a first-order engineering task.
- Release management
Feature flag
A feature flag is a runtime switch in code that turns a piece of functionality on or off without redeploying. Teams use flags to ship code dark, expose features to a subset of users, run A/B tests, and instantly disable broken features - decoupling deployment from release and shrinking the blast radius of a bad change.
- Observability
Golden signals
The golden signals are the four measurements Google's SRE book recommends watching on every user-facing service: latency, traffic, errors and saturation. Together they give a compact, high-signal view of health, so teams can spot regressions during a release, gate a canary promotion or trigger a rollback.
- Deployment patterns
GitOps
GitOps is a deployment pattern where a Git repository holds the declarative desired state of your system and an automated controller continuously reconciles the live environment to match it. Every change ships as a commit, every rollback is a `git revert`, and the repo - not a console or a one-off command - is the audit log.
- Reliability
Health check
A health check is a lightweight endpoint or probe a system calls to decide whether a service is alive and ready to serve traffic. Deploy pipelines, load balancers and orchestrators use its result to gate rollouts, route requests, restart unhealthy instances and trigger rollbacks - without waiting for a real user to hit a broken build.
- Release management
Hotfix
A hotfix is an urgent, narrowly scoped patch that fixes a critical bug in software already in production. It branches off the released tag, skips the queue of pending features, is tested in isolation, and ships out-of-band - so the live system stops bleeding without waiting for the next planned release.
- Infrastructure patterns
Infrastructure as Code
Infrastructure as Code (IaC) is the practice of declaring servers, networks, queues and other cloud resources in version-controlled files - typically Terraform, Pulumi, CloudFormation or Ansible - so an automated tool, not a human in a console, provisions them. Every environment becomes reproducible, every change reviewable, and rebuilding from scratch is one command.
- Infrastructure patterns
Immutable infrastructure
Immutable infrastructure is a delivery pattern where servers, containers and runtime environments are never modified after they are provisioned - to change anything you build a new image and replace the old instance whole. Configuration drift becomes impossible, every running version maps to a known build, and rollback is just bringing the previous image back.
- Delivery quality
Manual approval
A manual approval pauses a CI/CD pipeline at a defined step and waits for a named human to click approve before the next stage runs. It is the built-in escape hatch for decisions a machine cannot make: change-management sign-off, business timing, coordinated release windows, and any deploy that needs a second pair of eyes.
- Repository patterns
Monorepo
A monorepo is one Git repository that holds many independent projects: apps, services and libraries sharing tooling, history and version numbers. Instead of one repo per project, everything lives together, and CI runs only the parts affected by each change, so unrelated services build independently while cross-project changes ship in a single commit.
- CI/CD practice
Merge queue
A merge queue is a CI/CD mechanism that lines up pending pull requests, rebases each on top of the current tip of the target branch, re-runs the required checks, and only merges when they pass. It prevents "semantic conflicts" - where two individually green pull requests break the trunk once combined - by making every merge sequential and re-verified.
- Governance & compliance
Policy as code
Policy as code is the practice of expressing organisational rules - security controls, compliance requirements, cost limits, deployment safety checks - as version-controlled files that a machine can evaluate automatically, so a CI/CD pipeline can decide whether a change is allowed to merge or deploy instead of waiting for a human reviewer to read a wiki.
- CI/CD practices
Pipeline as code
Pipeline as code is the practice of defining a CI/CD pipeline in a version-controlled file (typically YAML or a DSL stored alongside the application code), so the build, test, and deployment workflow is reviewable, repeatable, and rolls forward and back with the rest of the repository - instead of being clicked together in a web UI that nobody can diff.
- Automation
Pipeline
A pipeline is an automated, ordered sequence of steps that builds, tests and ships your code every time it changes. Each step runs only if the previous one succeeds, so a single commit can flow from source control to a live environment without manual handoffs.
- Supply chain security
Reproducible build
A reproducible build always produces bit-for-bit identical outputs from the same source and inputs, no matter who runs it, when, or on which machine. It makes provenance verifiable: anyone can rebuild from source, compare hashes, and confirm the shipped artifact matches the claimed code.
- Release management
Release train
A release train is a fixed, recurring release schedule: every change that is merged and passing by the departure time rides that release, and anything late waits for the next departure. It gives teams a predictable delivery cadence, usually weekly, biweekly or monthly, so shipping stops being a per-change negotiation and becomes a scheduled event on the calendar.
- Operations
Runbook
A runbook is a written, step-by-step procedure engineers follow to run a system or handle a specific event - deploying a service, restarting a queue, rotating a secret, or recovering from an outage. Good runbooks are short, current, and often executable, so on-call responders can act quickly under pressure.
- CI/CD infrastructure
Self-hosted runner
A self-hosted runner is a build agent you run on your own infrastructure (a VM, container or bare-metal host) that your CI/CD system dispatches jobs to. It replaces the vendor's shared cloud runners so you control the network, cached dependencies, hardware and security boundary, at the cost of operating the machine yourself.
- Security
Secrets management
Secrets management is the practice of storing, distributing, and rotating sensitive credentials - API keys, database passwords, tokens, certificates - so pipelines, applications, and infrastructure can use them at runtime without ever exposing the raw values in source code, build logs, or version control. Access is scoped per identity, audited, and revocable on demand.
- Reliability practices
Service Level Objective
A Service Level Objective (SLO) is a measurable reliability target for a service, such as 99.9% of requests succeed over a rolling 30 days. It defines what engineering and product agree the service must meet, and it anchors the error budget, alert thresholds, and release policies that follow from that promise.
- Application architecture
Twelve-factor app
The twelve-factor app is a set of twelve principles for building software-as-a-service applications that deploy cleanly on modern platforms: explicit dependencies, config held in the environment, stateless processes, port binding, disposability and strict dev/prod parity, so the same codebase behaves the same way in every environment.
- Branching strategies
Trunk-based development
Trunk-based development is a source-control workflow where every engineer integrates small changes into a single shared branch - the trunk - at least once a day. Branches are short-lived, the trunk is always releasable, and unfinished work hides behind feature flags so deploys decouple from releases.
Suggest a new word or an edit to an existing one. Every submission is reviewed before it goes live.