Стратегия отката миграции первой среды выполнения EF Core Code с непрерывным развертыванием - PullRequest
Новая
       126

Стратегия отката миграции первой среды выполнения EF Core Code с непрерывным развертыванием

2 голосов
/ 19 июня 2020

У меня есть служба, которая использует миграции среды выполнения EF Core при запуске: 

var migrator = dbContext.Database.GetService<IMigrator>();
await migrator.MigrateAsync("targetMigration", cancellationToken);

Чтобы сгенерировать миграции, я сначала обновляю класс DbContext, а затем выполняю «do tnet ef migrations add» для создания код миграции.

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

Я могу представить себе рабочий процесс, например:

  1. Измените DbContext и выполните команду «do tnet ef add migration», чтобы сгенерировать код миграции

  2. Отмените изменение DbContext и разверните приложение так, чтобы код для миграции «n» существовал, но целевая миграция в MigrateAsyn c и версия DbContext была «n-1»

  3. Повторно примените изменение DbContext, измените MigrateAsyn c на целевую миграцию 'n' и разверните приложение

Но это кажется неудобным, и я не уверен, что это необходимо , и будет ли это определенно работать.

Какова хорошая стратегия для развертывания первых миграций времени выполнения кода с использованием EF Core, чтобы при развертывании предыдущей версии миграцию можно было автоматически откатился?

1 Ответ

1 голос
/ 19 июня 2020

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

Сначала вам нужно создать процесс, когда изменение должно быть очень хорошо протестировано, когда изменение попадет в производство, вы должны быть на 99% уверены, что в продукте не будет откатов.

Как вы говорите, вам понадобится последняя версия кода, в противном случае EF не будет знать, что делать "вниз".

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

dotnet ef migrations script 20190725054716_Add_new_tables

Это действительно сложная проблема, Java и JPA разделяет ту же проблему при создании истории.

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

Еще одну идею можно найти здесь :

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

...