Здравствуйте, Mr.Delphist, Вы писали:

MD>И если с исходниками вопросов нет, то вот по управлению миграциями базы есть вопросы. Допустим, есть два параллельных бранча, в них разработчики делают конфликтующие изменения (например, первый бранч предполагает добавление колонки в таблице, а второй или делает сущность коллекцией сущностей, или вообще удаляет её).
Само существование такой проблемы уже указывает на большие проблемы в планировании работ.
Как минимум потому, что в таком сценарии систему нужно будет тестироваьь 3 раза.

MD>Преположение: представим, что размер БД весьма крупный (и нужный для acceptance), и обычной локальной девелоперской пустышкой тут не отделаться (как минимум на QA-стадии)
MD>Вопрос: как лучше управлять деплоями этих бранчей на QA-среду, если у тестера может быть разный порядок тестирования этих бранчей? Каждый раз начинать из некоторого эталонного бэкапа, на который затем уже накатываются разрушающие миграции? Или есть идеи поинтереснее?
Насколько крупный? Если до нескольких гигабайт — то нет проблем сделать копию базы