Смена модели — это миграция, а не переключение

Смена модели — это миграция, а не переключение В прошлую пятницу я изменил одну переменную среды, направил функцию ответа в службу поддержки на другого провайдера и пошел домой, чувствуя себя умным. В понедельник в задании экспорта было три дня строк, в которых return_days было нулевым, и никто не пометил это, потому что пользовательский интерфейс отображал текст ответа и спокойно игнорировал отсутствующее поле. Моим первым инстинктом было обвинить новую модель. Моим вторым, более честным инстинктом было спросить, почему я внес изменение, влияющее на схему, без каких-либо приспособлений, без дифференциала и вообще без вентилей. Мы прекратили миграцию баз данных путем ручного редактирования SQL в рабочей среде много лет назад, так почему же мы до сих пор заменяем то, что генерирует наши постоянные данные, редактируя строку конфигурации? Я изложу свою позицию прямо, потому что хеджирование здесь никому не поможет: смена модели — это миграция, а не переключение. Выходные данные попадают в столбцы вашей базы данных, классификатор повторов, файлы экспорта и почтовый ящик вашего клиента, что означает, что вы несете обязательства по схеме в тот момент, когда вы ее сохраняете. Переключение подразумевает чистую обратимость без остатка, и любой, кто откатил наполовину примененную миграцию, знает, насколько это фантастика. Так что полезный аргумент не в том, какая модель победит в этом месяце.