Schema changes safely.
WHAT A MIGRATION IS
A versioned, repeatable schema change, committed with the code.
WHAT TO ALWAYS PROVIDE
A way to reverse it, where possible.
WHAT TO BE CAREFUL WITH
Migrations locking large tables Changes incompatible with the currently running code
WHY THAT SECOND POINT MATTERS
During deployment, old and new code may run simultaneously.
WHAT THAT REQUIRES
Changes compatible with both versions.
HOW TO ACHIEVE THAT
Add a column, deploy code writing to both, migrate data, deploy code reading the new one, then remove the old.
WHY THAT SEQUENCE
Each step is independently safe and reversible.
WHAT NOT TO DO IN ONE STEP
Rename or remove a column that running code uses.
WHAT TO TEST
Migrations against a copy of production-scale data.
WHY
A migration taking seconds on development data can take hours on production data, locking the table throughout.
WHAT TO RECORD
Which migrations have been applied.
WHAT TO BACK UP
Before applying any migration.
WHAT TO AVOID
Applying migrations manually and inconsistently across environments.
