Why deploys feel scary
Most teams do not fear deployment itself. They fear the 2am rollback, the migration that locks the users table, and the “it worked on staging” mystery. The fix is not courage — it is a setup where each deploy is small, reversible, and boring.
1. Make deploys small and frequent
A deploy with 400 changes is a gamble. A deploy with 4 changes is a non-event. Ship to production daily, behind the safety nets below, and each release stops feeling like an event.
- Keep pull requests small and reviewable
- Deploy on green main, not on a schedule
- Never bundle a risky migration with a risky feature
2. Run two versions side by side
Blue-green and rolling deploys share one idea: the new version takes traffic gradually while the old one is still warm and ready.
- Blue-green: switch the router once the new pool is healthy, keep the old pool for instant rollback
- Rolling: replace instances a few at a time and pause on the first failing health check
- Either way, going back is one command, not a redeploy
3. Health checks that actually gate traffic
A health endpoint that always returns 200 is decoration. Gate traffic on checks that prove the app can serve: database reachable, migrations applied, dependencies responding.
/healthfor the load balancer,/readyfor deploys- Fail closed: an unhealthy instance gets no traffic
- Watch the first minutes of every rollout, automatically
4. Migrations that never break running code
The golden rule: the database must work with both the old and the new code at the same time. Expand first, migrate data, then contract.
- Add columns and tables before the code that uses them
- Backfill data in a separate step, then enforce constraints
- Remove old columns only after the new version is everywhere
5. Hide the risky bits behind flags
Feature flags decouple deploying from releasing. Code ships dark, you enable it for 5% of traffic, watch the metrics, then roll forward — or switch it off in seconds.
6. Rehearse the rollback
An untested rollback plan is a hope. Practice going back on staging until it is one command and under five minutes, and write down who decides to pull the trigger.
Checklist before you merge
- Small diff, green pipeline, migration is expand-only
- Health and readiness checks updated
- Flag defaults to off for risky changes
- Rollback command known and tested
- Somebody owns watching the rollout
Do this consistently and Friday-afternoon deploys stop being a dare. If you want guided practice, our DevOps course walks through each of these on a real pipeline.