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 deployment process was a Google Doc with 23 steps. SSH into server A, pull latest code, run migrations, restart the process, check logs, SSH into server B, repeat. The document had comments like "ask Dave about this step" and "skip step 14 on Tuesdays." One misstep in the sequence left servers running different versions. The process took 45 minutes and could only be done by two senior engineers who had memorized the quirks.
When one of those engineers went on vacation, the other got sick. Nobody could deploy. A critical security patch sat undeployed for 5 days.
Deployment automation replaces the runbook with a script or pipeline that executes every step identically, every time, on every environment. The deployment becomes a single command or an automated trigger. Any engineer can deploy. The process takes minutes instead of 45 minutes. And it produces the same result whether it is Monday morning or Friday at 5 PM.
| Component | What It Does | Tools |
|---|---|---|
| Build artifact | Immutable package of your application | image, JAR, Go binary, tarball |
| Deployment orchestrator | Runs every step in sequence, handles failure | Argo CD, Spinnaker, Octopus Deploy, Harness |
| Environment config | Environment-specific values injected at deploy time | ENV vars, K8s ConfigMaps, AWS SSM, Vault |
| Health checks | Verify the new version is alive and serving correctly | /health endpoint, K8s readiness probes |
| Rollback mechanism | Revert to previous version if health check fails | Previous Docker tag, Helm rollback, git revert |
Immutable deployments are the core principle. Never modify a running server. Instead, deploy a new version alongside the old one, shift traffic, then terminate the old version. This means:
Stripe's engineering blog documented in 2018 how they moved from in-place deployments (modifying running servers) to immutable container deployments. Deploy failures dropped by 90% and rollback time went from 30 minutes to under 60 seconds.