Library→First Way: Flow→Tools & Techniques→Continuous Deployment
Continuous Deployment
Every green build ships to production automatically. What makes that safe, how deployment strategies reduce risk, and why deployment frequency is a measure of team health.
Video Lesson
A video lesson for this topic is in development. The library articles and mission exercises cover the same material in the meantime.
CI vs. CD
Continuous Integration (CI) is the practice of automatically building and testing every commit. Continuous Deployment (CD) extends this: every build that passes tests is automatically deployed to production. No human approval step. No scheduled release window. No deployment meeting.
The distinction matters. Many teams practice CI but not CD — they automate the tests but still deploy manually. This leaves the most error-prone and stressful step — the actual release — as a manual, human-dependent process.
Commit
CI
build + test
CD
deploy staging
CD
deploy production
CI stops at a verified artifact. CD takes that artifact all the way to production — automatically.
Continuous Delivery (with a capital D) means every build is releasable at any time — deployment is a business decision. Continuous Deployment means every passing build is released — the decision is automated. Both are better than manual.
Why automate deployment?
Manual deployments are unreliable
Every manual step is a place where humans can forget, skip, or do something different. Automated deployments run the same commands every time, in the same order, with the same configuration.
Small deployments are safe deployments
When you deploy once a month, each release contains hundreds of changes. When something breaks, you debug hundreds of candidates. When you deploy ten times a day, each release contains one or two changes. The blast radius is a line of code.
Fear of deployment is a smell
Teams that fear deployments make them rarer. Rarer deployments mean bigger batches. Bigger batches mean more risk. More risk means more fear. This is the deployment death spiral. Continuous deployment breaks the cycle.
Deployment frequency predicts performance
DORA research across 33,000 professionals shows that high-performing teams deploy 973× more frequently than low performers. Frequency is not a vanity metric — it reflects pipeline maturity, team trust, and technical quality.
Deployment strategies
Automated deployment does not mean reckless deployment. Deployment strategies control how the new version reaches users — giving you the ability to detect problems early and roll back instantly.
Rolling deploy
New version replaces instances one at a time. Old and new versions run simultaneously during the transition. Simple, low overhead.
Rollback risk: Low
Blue-green deploy
Two identical environments. Blue runs production. Green gets the new version. Switch traffic instantly. Rollback by switching back.
Rollback risk: Very low
Canary release
Route 1–5% of traffic to the new version. Monitor for errors. Gradually increase to 100% if metrics look good. Catch issues before full rollout.
Rollback risk: Very low
The strategy you choose depends on your infrastructure. A simple platform-as-a-service like Render uses rolling deploys by default. A more complex infrastructure might use canary releases with feature flags to control exposure.
The safety net: what makes CD safe
Continuous deployment is only safe when underpinned by a set of enabling practices. Without these, automated deployment is just automated risk.
Fast rollback
If you can deploy in 5 minutes, you can roll back in 5 minutes. Rollback must be as automated as deployment.
Comprehensive test suite
CD without tests is not CD — it is continuous breakage. The test suite is the gatekeeper. Every deployed commit must pass all tests.
Feature flags
Deploy code that is not yet user-visible. Separate deploy from release. Roll back a feature by toggling a flag, not by reverting a commit.
Observability
You must know within minutes if a deployment caused a problem. Metrics, logs, and alerts are not optional when deploying continuously.
The Nexus Corp deployment
In Mission 04, you connected Nexus Corp's GitHub repository to Render's auto-deploy feature. Every push to main that passes the GitHub Actions CI pipeline triggers an automatic production deployment on Render.
Before M-04: lead time of 43 days. After M-04: every commit to main is in production within minutes. The feedback loop that took weeks now takes the length of a coffee break.
Further reading
Accelerate — Forsgren, Humble, Kim
The DORA research. Chapter 2: Measuring Performance. Deployment frequency as a key metric of software delivery performance.
DevOps Handbook — Chapter 11
Enable and Practice Continuous Testing. How test automation enables deployment automation.
Continuous Delivery — Humble & Farley
Chapter 10: Deploying and Releasing Applications. The complete treatment of deployment strategies and rollback.
DORA State of DevOps 2023
The annual report. Elite performers: deploy on demand, multiple times per day. Measurement methodology and benchmarks.