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

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

Завдання. Два описи мали бути доказово ідентичними, автоматично, а не такими, у чию ідентичність час від часу вірять.

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

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