Plan the return journey
Your objectiveDescribe what would trigger rollback and how you would verify it.
Understand the idea.
A change plan should identify the intended state, the current state, the evidence of success and the return path. Rollback is not merely rerunning an old command: state may have changed while the new version was active. Data compatibility and side effects need separate attention.
A worked example.
An application deployment succeeds, but a key reader journey fails. A process-running indicator is not sufficient evidence to continue. A useful plan names that failure as a reason to stop and identifies the last known working release.
Try the reasoning.
For a small local change, write four lines: current state, intended change, success check and rollback trigger. Do not apply the change; this exercise is about the decision structure.
Carry it into practice.
Include application and data versions in the evidence so the recovery target is unambiguous.
Read the reference: FastAPI: deployment concepts ↗