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”
The CI pipeline was green. All 2,000 tests passed. The team deployed to production. Within seconds, every request returned a 500 error. The database connection string was wrong in the production environment configuration. No CI test had caught it because tests ran against a test database with a different connection string.
The outage lasted 8 minutes. That was 8 minutes of every user seeing error pages. Revenue loss was $47,000 (the company processed about $350K/hour in transactions). All because nobody had checked whether the application could actually connect to its dependencies after deploy.
Smoke tests run immediately after deployment against the actual running application in the target environment. They are not thorough. They verify the basics: the app starts, the health endpoint returns 200, the login page loads, the database connection works. If any smoke test fails, the deployment is automatically rolled back before users see the error.
The term comes from hardware engineering. When you power on a new circuit board, the first test is literally: does it smoke? If it does, turn it off. Smoke tests in software serve the same purpose. Is the building on fire?
Smoke tests verify the bare minimum for a deployment to be considered alive.
| Smoke Test | What It Verifies | Expected Result | Duration |
|---|---|---|---|
| Health endpoint | Application process is running | GET /health returns 200 | < 1 sec |
| Database connectivity | DB connection pool is working | Health endpoint includes db: ok | < 1 sec |
| Auth flow | Authentication service is reachable | POST /auth/login returns a token | 1-2 sec |
| Critical API | Core business endpoint responds | GET /api/products returns data | 1-2 sec |
| External dependencies | Third-party services are reachable | Payment gateway ping returns ok | 1-3 sec |
| Static assets | and asset serving works | GET /favicon.ico returns 200 | < 1 sec |
Total: 10-30 seconds. If your smoke tests take more than 60 seconds, they are too thorough. Smoke tests gate the traffic shift. Every second of smoke testing is a second that the new version sits idle while the old version serves traffic.
Netflix's deployment platform (Spinnaker) runs smoke tests as part of every . Their smoke suite has exactly 7 checks per service and completes in under 15 seconds. If any check fails, the canary is killed and the previous version stays live.