How do you handle rollbacks in a CI/CD pipeline?
Learn how to handle CI/CD rollbacks using blue-green and canary deploys, versioned artifacts, health checks, and safe backward-compatible database migrations.
Expected Interview Answer
You handle rollbacks by keeping previous known-good releases immutable and versioned, then automatically reverting to the last healthy version when health checks or metrics show the new deployment is failing.
Rollbacks are enabled by deployment strategies that preserve the old version: blue-green keeps the previous environment live so you can switch traffic back instantly, while canary and rolling deploys let you halt and reverse before full exposure. Automated health checks and monitoring trigger the rollback, and versioned immutable artifacts make reverting deterministic. Database schema changes require special care — use backward-compatible, expand-and-contract migrations so the old version still runs against the new schema.
- Restores service quickly when a release fails
- Reduces blast radius and downtime for users
- Makes reverts deterministic via versioned artifacts
- Enables automated recovery on failed health checks
- Builds confidence to deploy more frequently
AI Mentor Explanation
A rollback is like sending in a nightwatchman or reverting to a proven batting order when a new opener collapses. The team keeps the last successful line-up ready so it can be restored the moment the experiment fails. Blue-green deployment mirrors this: the previous, trusted eleven waits on the bench, and if the new selection struggles, the captain switches straight back with no time lost.
Step-by-Step Explanation
Step 1
Version immutable artifacts
Build every release as a uniquely tagged, immutable artifact so any prior version can be redeployed exactly.
Step 2
Choose a reversible strategy
Use blue-green, canary, or rolling deploys that keep the previous version available to switch back to.
Step 3
Add automated health checks
Wire readiness, liveness, and key metric checks that define what 'healthy' means for the new release.
Step 4
Trigger rollback on failure
When health checks or error/latency thresholds breach, automatically shift traffic back to the last good version.
Step 5
Handle database migrations safely
Use backward-compatible expand-and-contract migrations so the old version still works after a revert.
Step 6
Verify and alert
Confirm the restored version is healthy, notify the team, and capture the failure for a postmortem.
What Interviewer Expects
- Understanding of immutable, versioned artifacts
- Knowledge of blue-green, canary, and rolling strategies
- Automated health checks as rollback triggers
- Backward-compatible database migration handling
- Awareness of blast radius and fast recovery
- Post-rollback verification and alerting
Common Mistakes
- Assuming a redeploy of old code is safe when the database has already migrated forward
- Having no automated trigger and relying on manual detection
- Mutable artifacts that can't be reproduced for a clean revert
- Non-backward-compatible schema changes that break the previous version
- Rolling forward with a hotfix under pressure when a rollback would be faster and safer
- No monitoring, so failures are noticed only after user impact
Best Answer (HR Friendly)
“Rollbacks mean quickly going back to the last version of the software that worked when a new release causes problems. Teams keep old versions ready and use monitoring to detect failures, so they can automatically switch users back with minimal downtime.”
Code Example
# Deploy the new version
kubectl set image deployment/web web=myapp:v2
# Watch rollout health
kubectl rollout status deployment/web --timeout=120s
# If health checks fail, roll back to the last good revision
kubectl rollout undo deployment/web
# Inspect revision history
kubectl rollout history deployment/webFollow-up Questions
- How do blue-green and canary deployments make rollbacks easier?
- How do you roll back safely when a database migration has already run?
- What is the difference between rolling back and rolling forward?
- What metrics would automatically trigger a rollback?
- How do feature flags reduce the need for a full rollback?
MCQ Practice
1. Which deployment strategy lets you switch traffic back to the previous version almost instantly?
Blue-green keeps the previous environment live, so traffic can be redirected back to it instantly if the new release fails.
2. Why are backward-compatible database migrations important for rollbacks?
Expand-and-contract migrations keep the schema compatible with the previous version so a rollback doesn't break on the database.
3. What should typically trigger an automated rollback?
Automated rollbacks fire when health checks fail or error/latency metrics breach defined thresholds after a release.
Flash Cards
What is a rollback? — Reverting to the last known-good release when a new deployment fails.
Why use immutable versioned artifacts? — They make reverting to an exact previous version deterministic and reproducible.
How does blue-green aid rollback? — The previous environment stays live, so traffic switches back instantly.
What triggers an automated rollback? — Failing health checks or breached error/latency thresholds.
Why do migrations need care in rollbacks? — Backward-compatible schemas let the old version run after a revert.
Continue Learning
Related Interview Questions
What is CI/CD and what problems does it solve in software delivery?
easy
What is the difference between continuous integration, continuous delivery, and continuous deployment?
medium
How do you promote one immutable artifact across environments instead of rebuilding per stage?
hard
How do rollback mechanics differ between blue-green and canary deployments in practice?
hard