Непрерывная интеграция с EF Code Первые миграции

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

В настоящее время моя непрерывная интеграция просто обновляет изменения кода, однако я вручную создаю миграцию и обновляю базу данных на моем сервере непрерывной интеграции.

Является ли это надежным/возможным/рекомендуется создавать миграции и автоматически обновлять базу данных?

Например:

У меня есть пользователь с именем userId и именем пользователя. Затем я добавляю возраст к возрасту в код. В текущем сценарии мне потребуется создать миграцию, которая зафиксирует это изменение, а затем я проведу изменения в управлении версиями. Непрерывная интеграция обнаружит это изменение и развернет новую версию. Мне нужно вручную обновлять базу данных (которая должна быть автоматизирована).

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

Ответы

Ответ 1

Ответ - да, но не совсем так, как вы описываете.

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

Затем ваш CI-сервер может использовать файл migrate.exe, чтобы ваши базы данных синхронизировались с вашей моделью. Трудная часть - обработка миграций, которые приводят к понижению. Поэтому переход от v1 к v2 прост, но от v2 до v1 сложнее, поскольку только сборка v2 знает, как получить "назад" к v1.

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

Конечный результат заключается в том, что я могу проверить изменение/перенос модели и знать, что мое изменение db будет автоматически развернуто в любой среде, которая является частью моего конвейера ci/cd, и да, что абсолютно включает в себя производство.

Ответ 2

Часть непрерывной интеграции также является возможностью отката плохих изменений, если они не проходят тесты.

  • Вы пишете сценарии обновления базы данных таким образом, чтобы их можно было также понизить?
  • Создаете ли вы резервные копии резервных копий для каждой фиксации?
  • Вы потеряли бы данные в базе данных в случае резервного копирования/восстановления при плохих коммитах?
  • Что такое плохое изменение в самом DDL?

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