Эволюционная миграция баз данных и данные по умолчанию

Question

Мы пересматриваем процесс обновления базы данных для нашего приложения, чтобы попытаться устранить боль при создании всех сценариев обновления для выпуска в конце цикла выпуска. Мы стремимся к более эволюционному процессу, используя миграции, которые проверяются рядом с функциями с помощью такого инструмента, как migratordotnet, и это кажется очень простым способом управления изменениями схемы.

Однако данные по умолчанию, которые поставляются вместе с нашей базой данных, вполне могут подвергаться изменениям, и некоторые из этих обновлений данных не соответствуют требованиям процесса миграции. Например, вставки в таблицы, имеющие первичный ключ Identity, нелегко идентифицировать и поэтому не могут быть отменены при понижении.

Так что мне интересно, как люди управляют миграцией данных по умолчанию? Удалось ли им управлять за пределами процесса миграции схемы? Или вставки, выполненные во время миграции, но удаление данных не выполняется во время понижения?

Answer 1

Для нас миграция БД является частью ежедневного процесса разработки. Разработчики должны либо выполнить программу, либо скрипт, который выполняет необходимые изменения. Это происходит, как только соответствующая функция реализована и никогда не «в конце цикла выпуска».

Даунгрейд редко бывает проблемой, но если у вас есть это, создайте столбец с информацией о версии. Когда обновление будет успешным, и клиент решит остаться с новой версией, снова удалите столбец (или сохраните его).

Ключом к успеху является то, что у нас есть обширные тестовые примеры, которые создают базу данных с нуля (с использованием встроенной базы данных, такой как H2 или DB, которая установлена ​​на каждой машине разработчика), включая все данные, а затем перенести все путь через и обратно. Мы можем импортировать анонимные данные с серверов производства в тестовые примеры, чтобы отслеживать ошибки и улучшать тесты, не нарушая конфиденциальность наших клиентов или не мешая разработчикам.