- 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.
- CI/CD infrastructure
Build cache
A build cache stores intermediate outputs from previous CI runs - downloaded dependencies, compiled objects, Docker layers, test fixtures - so the next build reuses them instead of rebuilding from scratch. Keyed by a hash of the inputs that would invalidate the output, it turns most of a pipeline's work into fast lookups rather than repeated computation.
- CI/CD infrastructure
Build matrix
A build matrix runs the same CI job in parallel across a grid of dimensions - operating systems, language versions, dependency sets, target architectures - so one pipeline verifies every supported combination in a single run. Each matrix cell is an independent job with its own log, exit status and artifacts.
- Artifact distribution
Container registry
A container registry is a service that stores, versions and serves container images and other OCI artifacts. Build pipelines push images after a build; deployment targets pull them back by tag or content-addressed digest. Alongside storage the registry handles authentication, retention, cross-region replication, and vulnerability scanning of what you ship.
- 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.
- Delivery automation
Deploy hook
A deploy hook is a URL that triggers or reports on a deployment. Incoming hooks accept an HTTP POST that starts a build or release, so external systems can kick off deploys without direct CI access. Outgoing hooks fire after a deploy finishes so cache purgers, monitors, chat channels and dependent pipelines can react without polling.
- Deployment
Deployment target
A deployment target is the specific environment or endpoint that a pipeline promotes a build into: a Kubernetes namespace, a virtual machine, a static hosting bucket, a serverless function, or a managed container platform. Each target has its own address, credentials and health signals, and the pipeline chooses between them based on the branch, tag, or promotion stage.
- 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.
- Environments
Ephemeral environment
An ephemeral environment is a short-lived, isolated copy of an application spun up on demand (usually per branch or pull request) so reviewers, stakeholders and automated tests can exercise the change in production-like conditions. It lives long enough to review the change and is destroyed automatically when the PR merges or closes.
- 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.
- 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.
- Release safety
Roll-forward
Roll-forward is a recovery strategy that fixes a bad release by shipping a small corrective version through the normal pipeline, instead of reverting to the previous one. It trades the safety net of a known-good binary for the speed of a fast, trustworthy CD pipeline that can ship a fix in minutes.
- 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.
- 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.
- Environments
Staging environment
A staging environment is a production-shaped copy of your system where a release candidate is tested end-to-end before it reaches real users. It runs the exact artifact that cleared CI against production-like wiring, data and configuration, so the pass/fail signal on staging is a credible prediction of how the same build will behave in production.
- Testing & quality
Shift-right testing
Shift-right testing moves quality checks past the release, into production and production-like environments. Teams observe real users through canaries, feature flags, synthetic monitors and chaos experiments to catch issues that only appear under real traffic, real data and real third-party latency (failures no pre-release suite could realistically reproduce).
- SRE
Toil
Toil is the manual, repetitive, automatable operational work that scales linearly with a service - restarting a stuck job, rotating a certificate by hand, or copy-pasting the same deploy steps every week. Coined by Google SRE, it eats engineering time without producing lasting improvement and quietly caps how much a team can build.
- 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.