Entity Framework Migrations - Управление в филиалах

Question

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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