Pull to refresh

Comments 4

Допустим база накатилась. А дальше что? Выкатили софтина, а она не работает. Базу ответить нельзя, а старый софт не работает с новой базой. Или хуже того работает, но неправильно. И в любом случае не тестировался...

а что делать если такие кейсы:
1) генерируется пересоздание таблицы вместо обычного alter table? а в таблице несколько миллионов записей и пересоздание нам не надо.
2) несколько разработчиков выкатывают свои изменения схемы и вместе со схемой надо обновить какие-то данные и если это запускать единоразово — то скорее всего один из скриптов сломается.
1) Если нужен какой то кастомный SQL — он пишется в коде миграции через отдельные команды. Написать можно все что угодно, что не сломает механизм миграций.
2) Предполагается что прежде чем вы запускаете миграцию на боевой базе, вы точно такие же действия проводите на тестовой и там выясняете кто и что сломал. Описанный подход никак не отменяет тестирования. Порядок генерирования скрипта обновления в точности повторяет порядок миграций в вашем коде, этим вы можете управлять. Соответственно можно организовать этот порядок так, чтобы все было сделано правильно.
Для пункта 2 у MS где-то есть отдельная дока, как работать с миграциями в команде
Sign up to leave a comment.