Deployments including database tasks
Implement a deployment that includes database tasks
Databases are the part of a deployment that does not roll back cleanly. Application code can be swapped; data cannot be un-migrated without loss.
Backward compatibility is the whole strategy
Because application and schema deploy at different moments, the schema must be compatible with both the old and the new application version for the duration of the rollout. That is what makes a rollback survivable.
The standard sequence for a breaking change — renaming a column — is expand / migrate / contract:
- Expand — add the new column. Old code ignores it; new code can use it.
- Migrate — deploy code that writes both, backfill existing rows.
- Contract — only once no running version reads the old column, drop it.
Each step is independently deployable and independently reversible. A single rename is neither.
Ordering and gating
The migration stage runs before the application stage that depends on it, and — as with any dependency — completion is not readiness. Migrations should be:
- Idempotent, so a retried stage does not double-apply.
- Transactional where the engine allows, so a failure leaves no partial schema.
- Backed up first, because
on: failurecannot undo a destructive DDL.
The most dangerous deployment is the one whose rollback plan is "restore from backup" without anyone having tested the restore.
Primary sources