imtiazrayhan Write a plan responders can execute under pressure. Verify commands against repository and deployment configuration; label anything that cannot be confirmed.
Workflow
- Define release scope. List application artifacts, database migrations, configuration, feature flags, secrets, caches, queues, scheduled jobs, infrastructure, APIs, models/providers, and external dependencies changing together.
- Set objective triggers. Use error rate, latency, correctness, data integrity, SLO burn, queue depth, or business metrics with thresholds and observation windows. Name who declares rollback.
- Check compatibility in both directions. Confirm old code can run against new schema and data, new code can run during partial rollout, events remain readable, and configuration and secrets can be restored. Identify the point after which rollback becomes unsafe.
- Choose recovery paths. Define fast disable or feature-flag containment, application rollback, configuration rollback, traffic shift, and forward fix. State when each applies and when to stop trying it.
- Protect data. Describe dual-write or expand-contract phases, write freezes, backups or exports, reconciliation, queued-message handling, and irreversible effects. Never invent a down migration for data that cannot be reconstructed.
- Write exact commands. Mine workflow files, deployment manifests, runbooks, and scripts for artifact IDs, environments, namespaces, revisions, and flags. Include expected output and the next decision.
- Assign roles and communication. Name release lead, executor, verifier, database or platform owner, and communication owner. Include escalation thresholds and stakeholder channels.
- Verify recovery. Use the same health and business checks as the release gate. Define how long metrics must remain healthy, how data is reconciled, and which temporary containment steps must be removed.
- Rehearse. Dry-run commands in a safe environment or tabletop the sequence. Record untested assumptions and block the release when the only recovery path is speculative.
[!WARNING] A rollback command that has not been checked against the current deployment configuration is a hypothesis. Label it unverified and test it before approving the release.
Output
Create a Markdown rollback plan containing:
- release inventory and compatibility matrix
- trigger table with threshold, observation window, and decision owner
- containment, rollback, and forward-recovery decision tree
- exact commands with expected results and stop conditions
- database, event, cache, and external-side-effect handling
- roles, escalation, and communication
- verification and observation checklist
- rehearsal results, untested assumptions, and rollback cutoff point