Перенос кода EF Сначала в нескольких экземплярах

Question

У меня есть приложение MVC, которое сначала использует EF6 Code. Я хочу развернуть это приложение на нескольких датацентрах. В развертываниях, где есть миграции, я могу написать сценарий, чтобы перенести их все как можно раньше, но если один центр данных работает медленнее, тогда вызовы могут быть отклонены, поскольку схема больше не совпадает. Сценарий, который пытался координировать, также сделает невозможным скользящее обновление.

Есть ли способ сделать EF хотя бы попыткой выполнить запрос, даже если схемы не совпадают? Есть ли другой способ, которым я могу/должен подходить к этому?

UPDATE:

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

Вариант 1

1. Deploy для DC
2. код первой миграции работает на централизованной БД
3. запросы, сделанные DC A успешно, но запросы к DC B неудачу

Вариант 2

1. Развернуть до DC A
2. Не запускается автоматически миграциям
3. запросов, сделанных в DC неисправность и запросы к DC B продолжает преуспевать

Как разработать стратегию развертывания, которая будет делать это так, чтобы запросы либо DC будет работать ?

BTW: Я использую Azure Web Sites, если требуется решение для конкретной платформы.

Answer 1

В вашем посте вам показалось, что вы обеспокоены тем, как он будет себя вести во время фактического обновления. Ничего о тестировании. Но в комментариях вы просите о частичном развертывании, затем выполните тестирование. Поэтому, с одной стороны, вы бы хотели как можно быстрее развернуть, чтобы минимизировать время простоя. С другой стороны, похоже, что вы хотите развернуть на один сайт, протестировать и продолжать работать другие сайты, пока вы проверяете первое развертывание?
Проверка развертывания разумная, но довольно сложная. Я не уверен, что вы найдете много способов автоматизации для этого. Я думаю, что вы должны тщательно протестировать его до развертывания, а затем просто развертывать как можно быстрее в процессе производства. Если возникла проблема, которую вы обнаружили только при развертывании на производстве, вы столкнулись бы в плохом состоянии, потому что теперь ваш сайт не работает, пока вы не сможете его исправить. Даже если вы могли бы заставить другой экземпляр работать с новой базой данных, это рискованно, поскольку он будет изменять действия против схемы, которые он не понимает полностью. Кроме того, если вам нужно откат DDL, вы почти наверняка потеряете все данные, которые были изменены с момента развертывания. Поэтому лучше всего, чтобы все экземпляры старой схемы завершились с ошибкой до тех пор, пока они не были обновлены, чтобы предотвратить их изменение данных, которые могут быть потеряны.

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

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