Ответ 1
Проще говоря, это не так.
EF Миграции и развертывание Azure - это два совершенно разных зверя. Развертывание Azure дает вам множество опций, в том числе обновление и размещение слотов, вы, вероятно, видели Разверните веб-приложение в Azure App Service, для других читателей это хорошая начальная точка.
В целом модель развертывания Azure связана с активными подключениями к стеку IIS/Web Site, в общем случае обновление обеспечивает непрерывный доступ пользователя, заставляя экземпляр развертываться из пула балансировки нагрузки и перенаправляя трафик на другие экземпляры. Затем он циклически проходит через экземпляры, обновляющиеся по очереди.
Это означает, что в любой момент времени во время развертывания обновления будет существовать несколько версий вашего кода, запущенных одновременно.
Если ваша модель EF не изменилась между версиями кода, то развертывание Azure работает как очарование, пользователи даже не знают, что это происходит. Но если вам нужно применить миграцию как часть переноса BEWARE
В общем случае EF загружает только модель, если совпадают версии кода и БД. очень сложно использовать EF Migrations и одновременно поддерживать несколько версий кода модели
EF Миграции в основном контролируются инициализатором базы данных. Подробнее см. Подробнее об обновлении базы данных с помощью переноса.
Как разработчик вы можете выбрать, как и когда будет обновляться база данных, но знайте, что если вы используете Mirgrations и обновления для развертывания:
- Новый код не будет легко запускаться против старой схемы данных.
- Если старый код/приложение перезапустится, многие стратегии инициализации по умолчанию попытаются перевернуть схему обратно, если это произойдет, обратитесь к пункту 1.;)
- Если вы столкнетесь с тем, что модель EF загружается с неправильной версией схемы, вы будете испытывать исключения и общие сбои, когда код пытается использовать элементы схемы, которых нет там
Простейшим способом управления переносом EF на реальном сайте является удаление всех экземпляров сайта для развертываний, включающих миграцию EF - Вы можете использовать страницу обслуживания или перенаправление, что до вас.
Если вы столкнулись с этой проблемой, вероятно, лучше всего вручную применить обновление БД, а затем, если оно не удастся, вы можете легко прервать развертывание, потому что оно еще не началось!
В противном случае разверните обновление, и первый экземпляр, который будет развернут, запустит миграцию, если инициализатор настроен для этого...
Если вы абсолютно должны иметь непрерывное развертывание как кода сайта/содержимого, так и обновлений модели, тогда переходы EF могут не быть лучшим инструментом для начала работы, поскольку вы найдете его очень ограничивающим OOTB для этого сценария.