A migration that drops a column and a release that stops using it have to happen in an order, and during a rolling deploy both versions of the application are running at once.
// release 1 — add the column, write to both, read the old one
// release 2 — read the new one, still write both
// release 3 — stop writing the old one
// release 4 — drop it
// at every point, an old instance and a new instance can both serve
// traffic against the same schema without either one erroring.Four releases for a column rename sounds absurd until the first rollback, which under this scheme is redeploying the previous artefact and nothing else. The alternative — a deploy that requires the migration and the code to land simultaneously — has no rollback that does not involve restoring a backup. It is worth relaxing for a table with ten thousand rows and a maintenance window, provided the row count is checked rather than assumed.