Automated Deployment With Rollback Project
Part of the DevOps Roadmap
In short
Every team can deploy when things go right. What impresses people is a deploy that notices it's broken and undoes itself before most users notice. That's this project.
Demonstrate a deployment strategy (blue-green or canary from Phase 6) with an automated rollback mechanism if health checks fail — showing you can handle the failure case, not just the happy path.
Think of it like this
The new dish on one table
A restaurant tries a new recipe on one table first while the old dish keeps cooking. If those diners make faces, the chef goes straight back to the old pot. Only if they love it does the new dish go to every table. Canary releases with rollback work the same way.
Watch it happen
A canary deploy with automatic rollback
1/5Version 2 starts alongside version 1. No users see it yet.
The big ideas
What you need to know
Must-have: a strategy
Pick blue-green (switch all at once with a quick switch back) or canary (shift a slice at a time). Explain why in the README.
Health checks that mean it
Check real behaviour, like error rate and a test checkout, not only 'the process is running'.
Rollback without humans
The pipeline itself decides and acts. A Slack message saying 'please roll back' doesn't count.
Mind the database
Keep schema changes backward compatible, so v1 still works if you roll back after v2 migrated the database.
See it in code
Walk through the code
1#!/usr/bin/env bash2set -euo pipefail3NEW_IMAGE="$1"4 5kubectl set image deploy/web web="$NEW_IMAGE"6 7if ! kubectl rollout status deploy/web --timeout=120s; then8 echo "Rollout did not become healthy, rolling back"9 kubectl rollout undo deploy/web10 exit 111fi12 13# Extra check: hit a real endpoint a few times14for i in 1 2 3 4 5; do15 curl -fsS https://shop.example.com/health > /dev/null || { kubectl rollout undo deploy/web; exit 1; }16done1/4Fail fast on any error, and take the new image tag as the first argument.
A simple rolling-update version. Tools like Argo Rollouts or Flagger add true canary traffic splitting and metric checks on top.
Save yourself the pain
Common mistakes
Oops
Only testing the happy path in your demo.
Do this instead
Deploy a deliberately broken version on camera and show the rollback happening. That's the whole point of the project.
Oops
Dropping a database column in the same release that stops using it.
Do this instead
Use expand and contract: add new things first, switch code, and remove old columns in a later release.
Your mission
Milestone 1: break it and watch it heal
Quick check
In a canary release, what happens to most users while the new version is being checked?
Go deeper
- 1Implement a deployment strategy that includes automated health checks post-deploy.
- 2Simulate a failed deployment and confirm your rollback mechanism actually triggers correctly.
- 3Document the rollback trigger conditions clearly in your README.
More projects at this stop
End-to-End CI/CD Pipeline Project
Kubernetes Cluster Deployment Project
Infrastructure as Code Project (Terraform)
Monitoring Stack Setup (Prometheus + Grafana)
Multi-Environment (Dev / Staging / Prod) Setup
Portfolio Website or GitHub Showcase
Stuck on this topic? Ask an Insider
Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.
