Continuous Deployment: Shipping Code on Every Commit
Continuous Deployment isn't just automation; it's shipping every merged change to production automatically. It's for teams with high test coverage and robust monitoring to reduce lead time.
WHY IT EXISTS: To eliminate the delay and risk associated with manual, batched releases. By deploying every small, validated change automatically, you reduce the scope of any potential failure, making rollback or fix-forward trivial. It's the ultimate expression of shortening the feedback loop from code written to value delivered.
THE MENTAL MODEL: Think of your main branch as the direct remote control for production. A merged pull request isn't just 'done,' it's 'live.' This forces a culture of high quality, comprehensive testing, and robust observability, because there is no final human safety net before code reaches users.
HOW IT WORKS: A pipeline starts when a developer merges code into the main branch. This triggers a Continuous Integration (CI) process: build, unit tests, integration tests. If all pass, the Continuous Deployment (CD) system automatically deploys the new build to production. The process is watched by monitoring systems, with automated rollback triggers if key business or system metrics degrade.
WHEN TO USE IT: Use CD when your organization has a very high level of engineering maturity. This requires comprehensive automated testing (unit, integration, end-to-end), reliable infrastructure as code, robust feature flagging to decouple deployment from release, and sophisticated monitoring and alerting to detect failures instantly.
WHEN NOT TO USE IT: Avoid CD if your test suite is flaky or incomplete, if deployments are manual and error-prone, or if you lack real-time monitoring to detect failures. It's also a poor fit for systems with strict, scheduled release windows due to compliance or hardware constraints, like in embedded systems or some regulated financial applications.
ONE CANONICAL EXAMPLE: A developer fixes a typo on a website's pricing page. They create a pull request, which is reviewed and merged. The moment it's merged, the CI/CD pipeline automatically runs tests, builds the site, and deploys the change. Within minutes, the typo is fixed in production without any manual intervention from an operations team.
Read the original → en.wikipedia.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.