Миграции Entity Framework - управление ветвями

Question

Я использовал первые миграции для Entity Framework в настоящее время в совершенно новом проекте, и до сих пор они работали нормально в основной версии приложения.

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

Например (я явно упростили это ради обсуждения):

Отрасль A: Разработчик 1 добавляет миграцию «Add-UserDateCreated», который добавляет поле к объекту пользователя. Файл миграции содержит код для добавления поля и состояние модели в то время.

Отрасль B: Разработчик 2 добавляет миграцию «Add-UserMiddleName», которая добавляет другое поле в объект пользователя. Файл миграции содержит код для добавления поля, и в то же время имеет состояние модели (но у него, очевидно, нет поля, добавленного в другую миграцию).

Эти миграции прекрасно работают на ветвях, но когда вы объедините их обратно в ствол, то застревают:

• Вы не можете просто сохранить отдельные файлы миграции, сохраненной модели государства не будет быть верным. Например, миграция «Add-UserMiddleName» ДОЛЖНА иметь состояние модели с добавленным полем «Add-UserDateCreated», но это не так.
• Вы не можете объединить миграции в один файл, как вы нажмете тот же вопрос *

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

Так как же другие люди управляют такими ситуациями? Мне было бы интересно узнать мнение других народов.

* Мне любопытно, какие проблемы это действительно вызовет в реальном мире, если кто-нибудь знает?

Answer 1

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

Итак, в вашем примере разработчикам A и B необходимо установить связь друг с другом. Разработчик B, понимая, что требуется миграция, должен проверить, были ли выполнены другие миграции и объединить их с ее веткой, прежде чем создавать миграцию «среднего пользователя».

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

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

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