Entity Framework - Миграция в Azure - Реальный сценарий жизни - Понижение базы данных - PullRequest
Новая
       52

Entity Framework - Миграция в Azure - Реальный сценарий жизни - Понижение базы данных

3 голосов
/ 31 мая 2019

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

  • Веб-API , построенный поверх Entity Framework (сначала код) в Microsoft Azure .
  • Автоматическая миграция включена (автоматически мигрирует до последней версии)
  • У нас есть два слота - Производство & Постановка (оба имеют отдельную базу данных)

Давайте следовать этому сценарию:

  1. Мы развертываем новую версию в промежуточный слот (убедитесь, что все работает)
  2. Промежуточная база данных автоматически переносится на последнюю версию
  3. Мы своп подготовка экземпляр к производство слот
  4. Миграции run в production database
  5. Мы понимаем - по какой-то причине - нам нужно понизить версию и перейти к предыдущей версии.

ОК, теперь пришли все мои вопросы:

  1. Как нам понизить версию базы данных до предыдущей версии - (поскольку я не думаю, что это хорошая идея - подключиться к VS для производства и запустить команду downgrade из консоли диспетчера пакетов).
  2. Является ли рабочий процесс следующим: понизить версию базы данных до текущего экземпляра (что приведет к короткому времени простоя веб-приложения, поскольку миграции не будут совпадать), а затем заменить промежуточный (старый) промежуточный слот на рабочий слот?

Я некоторое время ломал голову над этим, так как не могу найти идеального способа сделать это - поскольку структура сущностей ломается, когда миграции не совпадают.

Ответы [ 2 ]

1 голос
/ 21 июля 2019

Вы можете создать сценарий SQL, который понизит базу данных.См. Раздел «Получение сценария SQL» этой статьи.

https://docs.microsoft.com/nb-no/ef/ef6/modeling/code-first/migrations/index#specific

В рабочем процессе мы «решаем», что текущая версия базы данных должна поддерживать более старую версиюверсии приложения.

Только после того, как поле или таблица не использовались в нескольких версиях, они фактически удаляются.У этого подхода есть недостатки: база данных может быть раздутой и грязной.Но это дает гибкость возможности установки более старых версий приложения.

0 голосов
/ 25 июля 2019

У нас есть аналогичные настройки в моей компании, и вместо использования миграций с первым кодом мы используем Fluent Migrator . Как часть кода запуска приложения, он выполняет все ожидающие миграции.

Точно так же, как любое решение, которое вы найдете, вам нужно будет написать код Up и Down, чтобы он знал, что делать для обновления и понижения.

...