- Deployment strategies
Canary release
A canary release rolls a new version out to a small slice of traffic first, watches it for errors and regressions, and only promotes it to the full user base once it looks healthy. The early traffic - the "canary" - acts as a live warning signal, limiting the blast radius of a bad change.
- 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.
- 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.
- 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.
- 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.
- Delivery practice
Continuous delivery
Continuous delivery is the practice of keeping software in a deployable state at all times by automating build, test and release steps into a pipeline. Every change that passes the pipeline is ready to ship to production at the push of a button - humans still decide *when* to release, but the machine does the work.
- Delivery practice
Continuous deployment
Continuous deployment is a release model where every code change that passes the automated pipeline ships straight to production, with no human approval gate in between. Tests, build and deploy run on every merge - so the lead time from a green commit to live users is measured in minutes, not weeks.
- CI/CD practice
Continuous integration
Continuous integration is the practice of merging every developer's code changes into a shared mainline many times a day, with each push automatically building, running tests, and producing an artifact. Catching integration problems within minutes - instead of during a painful merge week - keeps the codebase always close to releasable.
- 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.