2.5Rollback Plans

Every release should have a documented rollback plan before deployment begins. The worst time to figure out how to roll back is during an incident.

Rollback Plan Template

# Rollback Plan: v2.4.1

## Rollback Trigger
Conditions that trigger a rollback:
- Error rate exceeds 2% for more than 5 minutes
- p95 latency exceeds 5s for more than 5 minutes
- Any data corruption detected
- Critical functionality broken (login, checkout, payment)

## Rollback Decision
Who can authorize a rollback: [Engineering Manager] or [On-call Lead]

## Rollback Steps
1. Announce rollback in #engineering channel
2. Set status page to "Investigating"
3. Revert application to v2.4.0: [command or procedure]
4. Verify rollback: run smoke test suite
5. Assess database migration:
   - v2.4.1 migration IS backward-compatible: no database rollback needed
   - If database rollback IS needed: [procedure]
6. Update status page
7. Notify stakeholders

## Rollback Timeline
- Estimated time to rollback: 10 minutes
- Estimated time to verify: 15 minutes
- Total estimated downtime: 0 (rolling deployment)

## Post-Rollback Actions
- [ ] File incident report
- [ ] Schedule post-mortem
- [ ] Assess fix and re-release timeline