В чем заключается опасность использования EF Migrations (или какой-либо системы автоматической миграции) в производстве?

Question

Я рассматриваю возможность использования миграции Entity Framework 4.3 на производственном сайте.Меня беспокоит следующее:

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

На работе файлы сценариев хранятся в папке SQL (которую никто не может просмотреть) на сайте.Ранее запущенные файлы сценариев регистрируются в базе данных.Когда в папке появляются новые файлы сценариев (и их нет в базе данных), если пользователь является администратором, они будут перенаправлены на портал БД, в противном случае получит сайт для технического обслуживания.Если мы пытаемся выполнить сценарии с портала и не можем выполнить их, мы берем новые сценарии и пытаемся запустить их вручную в рамках экспресс-студии.Это работало более десяти лет.Я только изучаю миграцию, чтобы увидеть, не пришел ли лучший путь.Это не похоже на это.Пожалуйста, дайте мне знать, если есть лучший способ, и если это не миграция, что это такое.

Answer 1

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

При использовании миграций на основе кода, где каждый шаг миграции получает имя, можно создать отдельный сценарий миграции для использования при поднятии тестовой и расширенной сред. Желательно, чтобы он выполнялся на копии базы данных для проверки перед запуском в реальной среде prod.

Добавлено позже

Чтобы EF Migrations не могли выполнять какие-либо автоматические действия, можно использовать собственную стратегию инициализации. См. мой блог или Развертывание первых приложений EF Code в производственной базе данных Вопрос переполнения стека.