Plan and document a rollback strategy for my app before I need it in a real outage. Cover each of these: 1. Code rollback: how do I deploy the previous known-good release quickly? Confirm my platform supports rollback-by-tag or promote-previous-artifact, and write down the exact command or button click. If the pipeline always rebuilds instead of promoting an artifact, fix that so rollback doesn't depend on a rebuild working. 2. Config rollback: environment variables and feature flags. If I change a config and the app breaks, how do I revert? Config changes should be versioned somewhere, not edited in a dashboard with no history. 3. Migrations: irreversible migrations (dropping columns, renaming tables, changing types) make code rollback dangerous, because the old code won't run against the new schema. Audit my recent migrations and flag any that would break a rollback. Recommend the two-deploy pattern for schema changes: (a) add the new schema, deploy code that writes to both; (b) after a soak period, deploy code that reads from new only; (c) later, remove the old schema. 4. Data: identify any deploy that transforms existing data. Those need a backup taken immediately before, and a documented restore path. 5. Runbook: write a one-page 'rollback in progress' checklist I can follow at 2am without thinking. Who to notify, what commands to run, how to verify rollback succeeded, and what to check afterward. Don't propose blue/green or canary infrastructure I don't have; work with the deploy setup that actually exists. The deliverable is the rollback runbook checked into the repo, a note on any migrations that currently block clean rollback, and a dry-run rollback executed against staging so I know the mechanism works.