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

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

Цель этих всяких мигрилок типа flyway/Liquibase представить схему бд в виде исходников.

Концептуально правильный вариант — на каждую ветку разворачивать полноценное окружение, независимое от других. И пусть тестеры тестируют.

Тут, кстати, в очередной раз рулит монорепозиторий. Т.к. ветка там единая на все сервисы разом.

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

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

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

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

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

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

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

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

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

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

V>Само существование такой проблемы уже указывает на большие проблемы в планировании работ.

Безусловно, это ж Ынтырпрайз

V>Насколько крупный? Если до нескольких гигабайт — то нет проблем сделать копию базы

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

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

·>И чем это принципиально отличается от исходников? Вопросы ровно те же.

·>Цель этих всяких мигрилок типа flyway/Liquibase представить схему бд в виде исходников.

Схема — не проблема. Куда веселее, что часть миграций — неоткатываемая (без потерь данных). И если одному бранчу надо пристроить что-то сбоку, а другому — снести половину данных вдребезги пополам, то "куда крестьянину податься"?

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

vsb>Концептуально правильный вариант — на каждую ветку разворачивать полноценное окружение, независимое от других. И пусть тестеры тестируют.

Там много, ой много. Бабка за дедку, дедка за репку...

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

MD>·>И чем это принципиально отличается от исходников? Вопросы ровно те же.
MD>·>Цель этих всяких мигрилок типа flyway/Liquibase представить схему бд в виде исходников.
MD>Схема — не проблема. Куда веселее, что часть миграций — неоткатываемая (без потерь данных).
Это проблема серьёзнее. Почему они неоткатываемые? Надо делать откатываемыми. Терять данные можно только когда их никто не использует. Т.е. например, таблицу можно удалять при выкатке релиза только если ни старая, ни новая версия приложения её не используют.

MD>И если одному бранчу надо пристроить что-то сбоку, а другому — снести половину данных вдребезги пополам, то "куда крестьянину податься"?
В чём отличие от исходников-то? Да всё те же проблемы... Один бранч меняет что-то сбоку, а в другом рефакторинг всего... Подумайте о более безопасном процессе реорганизации кода.

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

V>>Насколько крупный? Если до нескольких гигабайт — то нет проблем сделать копию базы

MD>Много, реально много — мохнатое легаси и всё такое. Описанная ситуация — лишь выжимка от реальной картины. И если развернуть одну-две базы со скрипом ещё можно будет, это в любом случае не дотягивает до реального числа бранчей в разработке.

И все же, какой ориентировочно размер базы, чтобы понятен был масштаб проблемы?
Такое впечатление, что вы вместо прямолинейного подхода "на каждого программиста своя база (окружение)", пытаетесь что-то изобрести
Давно уже это все виртуализируется (см. например azure devtest labs), так что прямо устанавливать весь софт на физический комп не надо.

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

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

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

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

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

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

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


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

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

Q>Используем source control для бд, т.е. все объекты бд сохраняются в файлы в гит.

Это которая source control?

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

MD>Здравствуйте, Qulac, Вы писали:

Q>>Используем source control для бд, т.е. все объекты бд сохраняются в файлы в гит.

MD>Это которая source control?

Да вот например вот это

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

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

Q> Но если учесть, что каждый разработчик все равно работает со своей бд

Взаимоисключающие параграфы детектед

Реальный базы топикстартер озвучивать не хочет, отделывается общимии словами.
Я сам бы наверное усомнился в целесообразность простого подхода (своя база у каждого разработчика) при размере базы больше 100ГБ