- 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 process
Bake time
Bake time is the intentional waiting period after a new version starts serving real traffic - usually a canary slice or a first ring - before it is promoted further. The wait exposes slow-onset issues like memory leaks, connection pool exhaustion or delayed batch jobs that a quick smoke test would miss.
- DevOps platforms
Buddy
Buddy is a DevOps and Platform Engineering automation platform. CI/CD pipelines are one of around nine co-equal pillars, alongside remote deployments, environment lifecycle, app and static hosting, domain and DNS management, secure tunnels, git hosting and isolated sandboxes. Pipelines are configured visually in the UI or as YAML, and reachable via a REST API, the bdy CLI and Terraform.
- Infrastructure patterns
Configuration drift
Configuration drift is the gradual, undocumented divergence between what an environment should look like on paper and what it actually runs. Manual fixes, emergency patches and one-off tweaks pile up outside source control until two servers built from the same script quietly stop behaving the same way.
- Reliability practices
Chaos engineering
Chaos engineering is the discipline of deliberately injecting failures - killed processes, dropped packets, latency spikes, disk pressure - into a running system to learn how it actually behaves under stress, then fixing the weaknesses that surface before real users hit them. Netflix's Chaos Monkey turned the practice from thought experiment into a standard reliability tool.
- Delivery metrics
Change failure rate
Change failure rate is a DORA metric that measures the percentage of production deployments causing a failure: a rollback, a hotfix, or a user-visible incident. It signals delivery quality: a low rate means changes ship safely, while a high rate points to gaps in testing, review, or deployment automation that let defects reach users.
- 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.
- Release management
Deployment window
A deployment window is a scheduled span of time during which changes are allowed to reach production. Teams use it to concentrate risky releases into hours when experts are on hand, avoid peak traffic and change freezes, and give operations, support and customers a predictable, communicated cadence for updates.
- Delivery metrics
Deployment frequency
Deployment frequency is how often a team successfully releases changes to production. One of the four DORA metrics, it gauges delivery speed and the maturity of a team's CI/CD practice: elite performers ship on demand, multiple times per day, while low performers manage less than one production deploy per month.
- 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.
- 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.
- 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.
- 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.
- Delivery metrics
Mean time to recovery
Mean time to recovery (MTTR) is the average time it takes to restore a service after a production failure, from the moment an incident starts to the moment normal operation resumes. One of the four DORA metrics, it captures how quickly a team can detect, respond to, and recover from a bad change.
- 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.
- 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.
- Release management
Release candidate
A release candidate is a build that is functionally complete and considered ready for production, pending a final round of verification. Teams promote the same binary through staging, run smoke tests and acceptance checks against it, and either approve that exact artifact for release or reject it and produce a new candidate.
- Deployment strategies
Rolling deployment
A rolling deployment replaces old instances of an application with new ones a few at a time, so the service stays up throughout the change. Traffic shifts to healthy new instances as they come online while old ones drain - limiting downtime without provisioning the duplicate environment that blue-green requires.
- Supply chain security
SBOM (Software Bill of Materials)
An SBOM (software bill of materials) is a machine-readable inventory of every component that ships in a build: direct and transitive dependencies, exact versions, licenses, and cryptographic hashes. Generated at build time and attached to the artifact, it lets teams answer "is this vulnerable dependency in production?" in seconds instead of guessing across services.
- Release management
Semantic versioning
Semantic versioning (SemVer) is a version-numbering scheme that labels each release as MAJOR.MINOR.PATCH - bumping MAJOR for breaking changes, MINOR for backward-compatible features and PATCH for backward-compatible bug fixes. It gives consumers a predictable, machine-readable contract for what an upgrade will and will not break, so tooling and humans can reason about compatibility without reading changelogs.
- Deployment strategies
Shadow deployment
A shadow deployment runs a new version of a service in parallel with production and mirrors live traffic to it without affecting users. The new version processes real requests for observation, but its responses are discarded - so teams can validate performance, errors and behavior under genuine production load before any real rollout.
Suggest a new word or an edit to an existing one. Every submission is reviewed before it goes live.