Стратегия обработки нескольких миграций EF
Мне нужна помощь в формулировании стратегии действий в ситуациях, когда два или более члена команды выполняют миграцию EF независимо и по разным причинам. Каждый раз, когда мы сталкивались с этим сценарием, он полностью испортил снимок БД, а иногда и миграцию. Наши миграции более сложны, чем обычный шаблон, поскольку они содержат начальные данные и некоторые другие вещи, которые я не могу обсуждать. Но по сути происходит следующее: когда у нас есть две или более миграций, в наших снимках всегда возникают конфликты слияния и нет четкого пути их разрешения.
Я думаю, это в основном из-за того, что у меня есть один снимок, но
Если вы используете встроенный механизм заполнения, будет довольно просто воссоздать миграцию при слиянии. Предполагая, что «другие вещи» не предполагают большого количества ручного редактирования миграций.
Когда мы создаем PR, мы упоминаем, что это [МИГРАЦИЯ], что означает проверку с высоким приоритетом. После проверки разработчик, если есть новые миграции, объединенные в ветку develop, должен отменить миграцию, объединиться с develop и снова создать миграцию. Затем объединитесь с develop.
Если дополнительные миграции генерируются автоматически, вы можете удалить обе при слиянии и создать новую, содержащую оба изменения.
@SvyatlavDanyliv это хороший вариант. Пожалуйста, сделайте это ответом?
@jeb то же самое. Пожалуйста, сделайте это ответом.
Ответы 1
Предположим, у вас есть основная ветка разработки, например develop. Если кто-то объединяет миграцию в develop, объединять код миграции напрямую небезопасно. Вот как мы справляемся с этой ситуацией:
- Мы добавляем
[MIGRATION]к названию пул-реквестов, содержащих миграции. Это указывает на необходимостьHigh Priorityпроверки команды во избежание миграционных конфликтов. - При проверке запроса на запрос вы должны убедиться, что на момент вашего запроса в ветке
developнет новых миграций. - Если в
developуже применены миграции, вам следует ОТМЕНИТЬ свои миграции, объединить их сdevelop, воссоздать миграции, а затем как можно скорее объединить их сdevelop. Если кто-то отправит миграцию вdevelopв течение этого короткого периода, вам следует повторить этот шаг.
Мы пока этого не делаем, но слияние в develop можно ограничить DevOps-конвейерами:
- Если в вашем PR есть изменения в
DataContextModelSnapshot.cs, конвейер должен проверить, есть ли в вашей ветке PR все коммиты, которые изменили этот файл с момента ветвления. Слияние сdevelopрешает эту проблему. - Если не все коммиты найдены, слияние следует заблокировать. Вернитесь к шагу 3, чтобы исправить это.
Вариант 1: одна миграция за раз (что будет означать, что некоторым членам команды придется перестраивать свою миграцию после добавления другой): т.е. члены команды должны работать вместе. Вариант 2: миграция может не подойти в вашем случае; они очень хорошо работают в простых случаях, но это не значит, что они всегда являются правильным ответом (накладные расходы на сборку всех этих строк сгенерированного C# могут быть проблемой). Пойдите в старую школу и напишите SQL.