FluentMigrator Migration From Application_Start

Question

В настоящее время я изменяю нашу стратегию развертывания базы данных для использования FluentMigration и читаю о том, как ее запустить. Некоторые люди полагают, что он может быть запущен из Application_Start, мне нравится эта идея, но другие люди говорят, нет, но без указания причин, так что мои вопросы:

1. Это плохая идея, чтобы запустить миграцию базы данных при запуске приложения и если да, то почему?
2. Мы планируем перенести наши сайты на развертывание на облачные сервисы, а если мы не выполним миграцию из application_start, как это сделать/когда мы должны запускать его, учитывая, что мы хотим сделать развертывание максимально простым.
3. Где бы он ни работал, как мы гарантируем, что он работает только один раз, так как у нас будет сайт и несколько рабочих ролей (хотя мы могли бы просто обеспечить, чтобы код миграции вызывается только с веб-сайта, но в будущем мы можем увеличение до 2 или более экземпляров, будет ли это означать, что он может работать более одного раза?)

Я хотел бы получить любое представление о том, как другие обрабатывают миграцию базы данных во время развертывания, особенно с точки зрения развертывания на лазурный облачных сервисов.

EDIT:

Глядя на комментарии ниже я могу увидеть потенциальные проблемы во время работы Application_Start, возможно, проблема, я пытаюсь решить проблему с неправильным инструментом, если FluentMigrator не способ идти, и это может быть не в нашем случае, так как у нас есть большое количество хранимых процедур, представлений и т. д., так как часть миграции я должен был использовать SQL-скрипты, чтобы держать их в правильной версии и мигрировать вниз Думаю, это возможно.

Что мне понравилось в идее запуска во время Application_Start, было то, что я мог бы создать единый пакет развертывания для Azure и просто загрузить его в стадию, и миграция базы данных будет запущена, и это было бы, скорее, спасибо за запуск ручных скриптов, а затем просто поменяться на производство.

Answer 1

Выполнение миграций во время Application_Start может быть жизнеспособным подходом. Особенно во время разработки.

Однако есть некоторые потенциальные проблемы:

• Application_Start займет больше времени и FluentMigrator будет запускаться каждый раз, когда приложение Пул переработанный. В зависимости от конфигурации IIS это может быть несколько раз в день.
• Если вы это сделаете, пользователи могут быть затронуты, то есть попытаться получить доступ к таблице во время ее изменения, это приведет к ошибке.
• DBA обычно не одобряют.
• Что произойдет, если миграция завершится неудачей при запуске? Ваш сайт тогда?

Мое мнение ->

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

Answer 2

Альтернативный подход, который я использовал в прошлом, заключается в том, чтобы сделать ваши миграции неразрывными - вы пишете свои миграции таким образом, чтобы их можно было развернуть до изменения любого кода и работы с существующим кодом.Таким образом, оба кода и миграции могут быть развернуты независимо в 95% случаев. Например, вместо изменения существующей хранимой процедуры вы создаете новую или если вы хотите переименовать столбец таблицы, вы добавите новый.

Преимущества этого являются:

• Изменения в базе данных могут быть применены до каких-либо изменений в коде. Затем вы можете откатить все изменения кода или сломать миграцию.
• Нарушение миграции не займет существующего сайта.
• Администраторы баз данных могут выполнять миграцию самостоятельно.