We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Devops Cicd
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Devops Cicd
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A team's CI pipeline was green. Unit tests passed, integration tests passed, build succeeded. They triggered a deployment to staging. It failed. The application crashed on startup because it depended on a new environment variable that existed in CI but not in staging. The database migration required a column that had not been added yet. The config file referenced a secrets path that only existed on the CI runner.
CI validated the code. Nobody validated the deployment.
This happens more than you would think. Charity Majors (CTO of Honeycomb) has written about it repeatedly: "CI tells you the code compiles. It does not tell you the code deploys." Amazon discovered early that the gap between "tests pass" and "ready to ship" was where most of their deployment failures lived. Their solution was to automate the entire path from commit to production, not just the build and test stages.
Continuous delivery closes that gap. Every change is not just buildable and testable but actually deployable to a production-like environment. The entire path from commit to production is automated and validated. At any moment, you can push a single button and release to production with confidence.
The CI pipeline you already have is the first two stages. Continuous delivery adds everything after.
| Stage | What It Validates | Typical Duration |
|---|---|---|
| CI (build + test) | Code compiles, tests pass | 3-10 min |
| Deploy to staging | Application starts, config is correct, services connect | 2-5 min |
| Smoke tests | Critical user paths work in staging | 30-90 sec |
| Performance tests | Response times within SLA thresholds | 5-15 min |
| Security scan | No new CVEs, compliance checks pass | 2-5 min |
| Manual approval (optional) | Product or engineering sign-off | Minutes to hours |
| Deploy to production | One-click production deploy | 2-10 min |
The non-negotiable requirement: your main branch must always be deployable. If main is broken, nobody can release. Not even hotfixes. At Google, a broken main branch triggers an automatic investigation and is treated as a P1 incident on teams that practice CD.
When is CD premature? When you do not have automated testing, staging environments, or deployment automation yet. Continuous delivery is the result of mature CI, infrastructure as code, and automated testing. Trying to build CD before those foundations exist is like trying to furnish a house before the walls are up.