Тримала схему узгодженою впродовж 1 022 міграцій за допомогою перевірки CI, яка збирає базу даних обома шляхами — чиста інсталяція та інсталяція плюс усі міграції — і падає, коли вони розходяться.

Ситуація. У більшості проєктів схема описана двічі: один раз — початковим налаштуванням, яке будує її з нуля, а вдруге — міграціями, що накопичувалися, поки вона росла. Обидва описи мають давати ту саму базу даних. Ніщо не перевіряє, чи це справді так, тож вони розходяться — і розбіжність лишається невидимою, доки нове середовище не почне поводитися не так, як продакшн, зазвичай у найгірший момент.

Завдання. Тотожність двох описів треба було доводити автоматично, а не час від часу просто в неї вірити.

Дія. Версії бази даних — це 1 022 міграції з номерами від 036 до 1102, і дисципліна їх упорядкування нудна й не підлягає обговоренню. Тримається все на задачі в CI, яка під час кожної зміни збирає базу даних двічі: один раз зі свіжої початкової схеми, удруге — з початкової схеми, на яку по черзі накочено всі міграції, — а потім порівнює результати. Порівнює не лише структуру — це легша половина, — а й початкові дані, бо міграція, яка неправильно заповнює довідкову таблицю, шкодить рівно так само, як та, що забула колонку, а в diff схеми видно лише одну з них. Будь‑яка розбіжність зупиняє збірку й виводить різницю.

Результат. Нове середовище й те, що живе давно, — одна й та сама база даних, і це перевіряється, а не приймається на віру. Платить за це той, хто пише міграцію: вона має працювати і під час послідовного накочування, і з холодного старту, а це потребує більше роздумів, ніж зазвичай дістається швидкому ALTER. У цьому й суть: інакше про розбіжність дізнаються під час відновлення, коли відповідь критично важлива, а часу її шукати вже немає.