Comparison
Automated rollbackvsRoll forward
Automated rollback
error rate crossed the threshold ninety seconds in and the system reverted to the previous version without waking anyone.
Reverting a release automatically when post-deploy signals breach a threshold. It converts a class of incident into a non-event, and it depends entirely on the previous artefact still being deployable — which is a statement about migrations, not about the pipeline. Forward-only changes to schemas and data are exactly what make automated rollback impossible, which is why they deserve the scrutiny they get.
Full entry →Roll forward
you cannot go back because the migration already ran, so the only way out is to ship another change quickly.
Fixing a bad release by deploying a newer version rather than reverting. It is necessary when a rollback would be destructive — irreversible migrations, consumed messages, already-published events. It is riskier under incident conditions, so it should be a consequence of the change's shape, not a habit.
Full entry →