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

MD>Подумалось тут про сферического коня в базовом вакууме.

MD>Вот допустим, у нас есть проект, где мы ведём разработку в бранчах: отделились от некоторого условного DEV, далее разработчик педалит изменения, затем это проходит цикл QA-активностей, затем либо слияние с DEV, либо откладываем в сторону на N времени (бизнес передумал/думает, разработчика потащили на более приоритетную задачу и т.п. — не суть)

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

MD>Преположение: представим, что размер БД весьма крупный (и нужный для acceptance), и обычной локальной девелоперской пустышкой тут не отделаться (как минимум на QA-стадии)

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

MD>Стек Java/MySQL, хотя вряд ли это столь существенно.


Наивная реализация решает сразу все проблемы. Используем source control для бд, т.е. все объекты бд сохраняются в файлы в гит. Для тестов поднимаем новую бд из этих файлов. Недостаток — дорого в плане инструментов и может быть долго. Но если учесть, что каждый разработчик все равно работает со своей бд, тогда тестеру достаточно будет переключится на его бд и тестировать с ней — так будет быстрее.