DevOps & Delivery

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