Monochromatique,

гораздо интереснее вопрос, как пользоваться EF-миграциями при разработке в команде

ЕвгенийВhVosttMonochromatique,

гораздо интереснее вопрос, как пользоваться EF-миграциями при разработке в команде
А в чем проблема?

пока не попробуешь, не узнаешь

ЕвгенийВhVosttпока не попробуешь, не узнаешь
Пробовал, никаких проблем.
Если не считать того факта, что структуру БД ваяют тупые и убогие императивщики, а должны божественные базаданщики!

Если в команде 2 девелопара делают по миграции из одной и той же версии (развернутой у них локально), то потом такие миграции не встанут. Точнее встанет только одна, кто первый тот и папа. Второму придётся делать дополнительные манипуляции.

ЕвгенийВhVosttЕсли в команде 2 девелопара делают по миграции из одной и той же версии (развернутой у них локально), то потом такие миграции не встанут. Точнее встанет только одна, кто первый тот и папа. Второму придётся делать дополнительные манипуляции.
ХЗ.
Участвовал в одном провальном проекте, так там эти миграции именовались как то от номера спринта (или как его там) + текущая дата до секунды. Никаких проблем с вставанием миграций не возникало...

Ээммм... секунды тут не при чём, миграция основывается на конкретной предыдущей миграции. Я не в курсе какие у вас там были миграции, но Entity Framework хрен даст тебе сунуть свою миграцию, если кто-то постарался и успел сунуть свою. Не имеет значения ни номер спринта, ни дата до секунды, -- и это очень правильно.

Сама миграция стряпается на основе изменений, которые ты сделал и текущего состояния СУБД. Если же текущее состояние неизвестно (кто знает какие изменения нахреначили другие участники команды за один и тот же этап??), то невозможно сделать правильную миграцию.

ЕвгенийВhVostt,
А понятно. БД одна общая на всех?
У нас были отдельные локальные БД у каждого и каждый раз когда нужно было накатить, в БД все грохалось и начинало накатываться сначала, последовательно по номерам миграций.

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

Например, я переименовываю поле, а ты добавляешь это поле в индекс. Если твоя миграция пойдёт первой, то всё будет ок, а если наоборот, твоя сломается. И это самый простой случай. Часто миграции не только DDL, но ещё и с изменениями самих данных, тут вообще можно так накосячить, что не сразу об этом узнаешь. Именно поэтому не связанные друг с другом миграции -- зло, и не допустимо. ЧТобы пропихнуть свою миграцию, ты должен вытащить все имеющиеся, и получив актуальное состояние, сунуть свою. И так у каждого разработчика. Не важно общая БД или у каждого локальная, разницы никакой. Для EF имеются такие практики, как последовательная заливка своих миграций, с прогоном по общей базе в TeamCity, с тестами и прочим.

ЕвгенийВБазаданщик сделает хранимую процедуру.

В лес таких базаданщиков. Если он не собирается написать хранимку сразу под все популярные СУБД и потом успешно поддерживать их.