Rolling back a deployment means quickly restoring the last known-good version of an application after a critical bug is discovered in production, to minimize user impact while the root cause is investigated.
Key Points: • Stop or pause the current deployment immediately to prevent the broken version from spreading further. • Identify the last stable release, usually a tagged commit or a previous CI/CD artifact version. • Use the CI/CD pipeline or orchestration tool (Jenkins, Kubernetes) to redeploy that known-good version rather than manually patching production. • Run smoke tests or health checks against the rolled-back environment to confirm it's actually stable before declaring the incident resolved. • Investigate and fix the underlying bug in a separate branch, then go through the normal pipeline again before attempting to redeploy the fix.
Example: After noticing a spike in 500 errors right after a release, the team runs kubectl rollout undo deployment/api to revert to the previous ReplicaSet while engineers diagnose the faulty code offline.
Code Example:
kubectl rollout undo deployment/api
kubectl rollout status deployment/apiInterview Tip: A concise interview answer is:
"I'd immediately halt the bad deployment and redeploy the last known-good version through the same CI/CD pipeline, whether that's a Jenkins job or a kubectl rollout undo. Once traffic is stable again, I'd verify with health checks and only then investigate and fix the root cause before trying again."