DevOps & Delivery

Busted

• Affected buildsCI finds the projects touched by a change, including their dependents, and builds only those instead of rebuilding the whole monorepo.
• Artifact registryStorage for built things: images, packages, binaries. Deploys pull a finished build from it instead of rebuilding from source.
• Automated rollbackAutomatically restoring the last known-good release when post-deploy checks or production metrics show the new one is failing.
• Backward-compatible deploymentShipping so the new version and the old version can run side by side without either one choking on the other's data.
• Blue-green deploymentTwo identical production environments. Deploy to the idle one, flip all traffic at once, keep the old one warm for instant rollback.
• Branch protection rulesRepo settings that block direct pushes to main and require reviews plus passing checks before anything can merge.
• Branching strategyYour team's agreed rules for how branches get created, named, merged, and released, so git doesn't turn into a free-for-all.
• Build artifactThe frozen file, bundle, binary, or image a build produces and later deploys. Build it once, then move those exact bytes toward production.
• Build cacheReusing the outputs of previous builds so unchanged work is skipped. The reason a second CI run finishes in seconds, not minutes.
• Build matrixOne CI job repeated across chosen OS, runtime, architecture, or dependency versions, so compatibility claims get tested instead of assumed.
• Canary releaseReleasing to a small percentage of users first, watching the metrics, then widening or rolling back before it reaches everyone.
• Change failure rateThe share of production changes that cause trouble serious enough to need a rollback, hotfix, fix-forward, or incident response.
• Changelog automationRelease notes assembled from pull requests, labels, or commit conventions, so each release starts with a useful draft instead of a blank page.
• CI runnerThe machine or worker that picks up a CI job and runs its commands. Your workflow is the recipe; the runner is the kitchen.
• CI/CD pipelineThe automated chain that builds and tests every push, then delivers or deploys whatever qualifies, so nobody memorizes the steps.
• ContainerizationPacking your app plus everything it needs to run into one portable image, so it behaves the same way on almost every machine.
• Continuous deliveryKeeping every validated change packaged and ready for production, while a person or business decision still chooses when to release it.
• Continuous deploymentAutomatically releasing every change that passes the pipeline, with no person pressing a production release button.
• Continuous integrationEveryone merges small changes into main often, and a machine builds and tests each one, so breakage surfaces in minutes.
• Conventional CommitsA predictable commit message style that lets tools calculate version bumps and assemble release notes.
• Dark launchDeploying code to production while keeping the feature hidden, so it can be exercised safely before users are allowed to see it.
• Database migrationA versioned script that changes your database schema in a fixed order, so every environment ends up with exactly the same structure.
• Dependency pinning / lockfileThe build broke today and nobody changed code. A lockfile records exact dependency versions so every machine installs the identical tree.
• DeploymentTaking one specific build of your app and installing it into one target environment: production, staging, or a preview URL.
• Deployment freezeA defined stretch when routine production releases stop, usually because support is thin or the cost of disruption is unusually high.
• Deployment gateA check or human approval that must pass before a release can move to the next environment or reach production.
• Deployment strategyThe chosen way production moves from the old release to the new one, such as rolling, blue-green, canary, or recreate.
• DORA metricsFour signals that balance delivery speed with stability: deploy frequency, change lead time, recovery time, and failed-change rate.
• Drift detectionChecking whether live infrastructure still matches its version-controlled definition, so manual changes do not stay hidden.
• Environment parityKeeping local, staging, and production alike where behavior depends on it, so passing in one environment predicts passing in the next.
• Environment variablesConfig values fed to your app from outside the code, so the same build behaves differently on your laptop and in production.
• Ephemeral environmentA temporary full stack created for one branch or pull request, then torn down after review so changes can be tested in isolation.
• Expand-and-contract migrationChange a live schema safely: add the new shape, write both, backfill, switch reads, then remove the old shape in a later release.
• Feature flagA switch that turns a feature on or off at runtime, so code can ship to production while staying invisible to users.
• GitOpsKeeping deployed state in Git and letting a controller make the live system match what the reviewed repository declares.
• Health check endpointA tiny URL like /health that the platform polls to decide whether an instance gets traffic, gets restarted, or holds up the deploy.
• HotfixA small, urgent production fix released outside the normal schedule because waiting would cause more harm.
• Idempotent deploymentA deploy you can safely rerun: the same artifact and configuration converge on the same final state without duplicate side effects.
• Immutable infrastructureServers you never patch in place: to change anything, build a new image and replace the machine. No SSH surgery, no snowflake boxes.
• Infrastructure as codeDefining your servers, databases, and DNS in version-controlled files instead of clicking around a cloud console.
• Kill switchA single toggle that instantly disables a risky feature or integration in production, no deploy required.
• Maintenance windowAn announced period when planned work may degrade or interrupt a service, with users warned and operators ready to roll back.
• Preview deploymentA temporary live URL built automatically for every branch or pull request, so people can click the change before it merges.
• Production environmentThe live copy of your app: real users, real data, real money. Break it here and someone actually notices.
• Release candidateA frozen build believed ready to ship, tested as the possible final release and replaced by a new candidate if anything changes.
• Release tagA fixed version-control marker, usually v1.2.3, that identifies the exact commit whose code belongs to a release.
• Release trainA release that leaves on a fixed recurring schedule; ready features ship, and anything unfinished waits for the next one.
• Required status checksThe CI jobs that must report green before a pull request can merge. The checkmarks that hold the merge button hostage.
• RollbackRestoring the last known-good release when a deploy goes wrong, instead of scrambling to fix it live.
• Rolling deploymentReplace running instances a few at a time so the service never goes down, with old and new versions live together during the swap.
• Secret rotationReplacing a password, key, or token and moving every consumer to the new one before the old credential is revoked.
• Self-hosted runnerYour own machine running CI jobs instead of one supplied by GitHub or GitLab, useful for private networks, special hardware, or more control.
• Semantic versioningNumbering releases as major.minor.patch so the version signals whether an upgrade is intended to be breaking.
• Staged rolloutReleasing to a small group first, then expanding through planned percentages or cohorts over hours or days.
• Staging environmentA near-identical clone of the live site where you rehearse the release before real users see it.
• Trunk-based developmentEveryone merges small changes into main every day instead of nursing feature branches for weeks.
• Zero-downtime deployShipping a new version while the app keeps serving requests. A goal you engineer for, not something a deploy strategy hands you.

The territory

30 core terms mapped for this field, ranked by how often builders reach for them. Each one is a future entry. Want to bust one? One entry, one file, one pull request.

• deploymentinstalling a specific application build into a target environment"pushing the code live" · "putting the app on the server"
• CI/CD pipelineautomated build-test-deploy chain triggered by code changes"the thing that runs when I push" · "auto-deploy on commit"
• continuous integrationautomatically building and testing every merged code change"tests run on every push" · "the CI checks"
• production environmentlive environment serving real users and data"the real site" · "where actual users are"
• staging environmentproduction-like copy used for final checks before release"test site that looks real" · "the pre-live copy"
• rollbackreverting production to the last known-good release"undo the deploy" · "put the old version back"
• feature flagruntime toggle that turns code paths on without deploying"kill switch for a feature" · "ship it but hidden"
• preview deploymenttemporary live URL built per branch or pull request"link for every PR" · "throwaway site for this change"
• environment variablesper-environment config injected at runtime instead of hardcoded"the .env thing" · "config that lives outside the code"
• secrets managementstoring and injecting credentials safely outside source code"keys not in the repo" · "where do I put API keys"
• database migrationversioned, ordered schema change applied on deploy"changing the DB without breaking it" · "schema update script"
• zero-downtime deployreleasing without dropping requests or showing maintenance pages"deploy without going offline" · "no maintenance page"
• canary releaseship to a small traffic slice, watch, then widen"roll out to 5% first" · "test on a few users"
• blue-green deploymenttwo identical environments; traffic flips between them instantly"swap the live one" · "two servers, switch which is live"
• rolling deploymentreplace instances gradually so some old, some new run"swap servers one at a time" · "gradual replacement"
• kill switchone flag that instantly disables a risky feature or integration"the big red off button" · "turn it off right now"
• branch protection rulesrequired checks and reviews before merging to main"stop people pushing to main" · "rules on the main branch"
• required status checksCI jobs that must pass before merge is allowed"the green checkmarks" · "tests have to pass to merge"
• smoke testtiny post-deploy check that the app basically works"quick did-it-break check" · "hit the homepage after deploy"
• health check endpointURL the platform polls to decide if an instance is alive"the /health thing" · "how it knows the server is up"
• backward-compatible deploymentnew code that works with old data and old clients"won't break the old version" · "safe while both are running"
• infrastructure as codeservers and services defined in version-controlled config files"servers in a config file" · "no clicking in the console"
• containerizationpackaging an app with its dependencies into a portable image"runs the same everywhere" · "box up the whole app"
• trunk-based developmenteveryone merges small changes to main frequently"no long branches" · "just commit to main"
• branching strategyagreed rules for how branches are created, merged, released"how we organize branches" · "our git rules"
• semantic versioningmajor.minor.patch numbering that signals breaking changes"the 1.2.3 numbers" · "how to number releases"
• dependency pinning / lockfileexact dependency versions recorded for reproducible builds"why my build changed on its own" · "lock the versions"
• build cachereusing prior build outputs so repeat builds are fast"why is CI so slow" · "don't rebuild everything"
• artifact registrystorage for built images, packages, binaries between build and deploy"where the builds live" · "place to keep docker images"
• immutable infrastructurereplace servers instead of patching them in place"never SSH in to fix" · "rebuild instead of repair"

Deeper in the field

• continuous delivery keeping validated changes ready for a production release
• continuous deployment automatically releasing every validated change to production
• dark launch deploy code to production without exposing it to users
• staged rollout releasing to expanding audience percentages over days
• hotfix urgent production fix released outside the normal workflow
• automated rollback automatically restoring the previous release when checks fail
• deployment strategy chosen method for replacing an existing production release
• deployment gate automated check or approval required before a release proceeds
• release candidate a build frozen for final validation before becoming the release
• release tag version-control marker identifying the exact code included in a release
• build artifact immutable output produced by a build and later deployed
• CI runner machine or process that executes pipeline jobs
• self-hosted runner your own machine executing CI jobs instead of the vendor's
• build matrix running the same CI job across OS, runtime, or version combinations
• affected builds CI only rebuilds what the change actually touched
• environment parity keeping development, staging, and production configurations closely matched
• ephemeral environment short-lived full stack spun up per branch, destroyed after
• expand-and-contract migration add new schema, dual-write, then remove old safely
• idempotent deployment rerunning the same deploy produces the same result
• changelog automation release notes generated from commit messages or PRs
• conventional commits structured commit message format that drives versioning and notes
• secret rotation scheduled replacement of credentials without downtime
• drift detection spotting when live infrastructure diverges from its declared config
• GitOps git repository is the single source of truth for deployed state
• release train fixed, recurring release schedule regardless of feature readiness
• deployment freeze period when no releases ship, e.g. holidays
• maintenance window announced period when degradation or downtime is acceptable
• DORA metrics four delivery benchmarks: frequency, lead time, MTTR, failure rate
• change failure rate percentage of deploys that cause an incident or rollback