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

Уточните, из-за чего именно мучаетесь ;)

Trunk based development

Тогда как вариант

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

Мержить схемы имхо не вариант)

Лучше заново имплементации делать

Тем более большие схемы и сложные

Возможно вы там чот визуально программируете, схемы должны реже меняться, чем код)

Ну или бизнес прёт

В чем (Гитлаб, Битбакет и т. п.) Вы храните код и BPMN-диаграммы?

гитлаб. стандартно. виливаем вместе с кодом. если так случается, что попадаются задачи +- в одном месте ответвляемся от процесса где больше всего правок. по результату более менее чет получается собрать, такие случаи скорее исключение.

Угу, я так и предполагал, просто хотел убедиться.

Нельзя, чтобы несколько человек параллельно редактировали одну bpmn схему в моделере.

Схемы вместе с собственно постановкой задачи, юзер-стори, пользовательские сценарии сначала надо обсудить и понять всей командой (по BDD - 3 amigos - продакт+программист+тестировщик). Обсуждение командное, но рисует схему один человек.

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

Для bitbucket, если вдруг у вас он, есть плагин bpmn-diff - показывает визуально разницу между тем, что было на схеме и как стало. Без битбакета - можно делать нечто подобное руками.

В остальном специфики именно камунды нет. О проблемах монолита/монорепозитария с большой командой написано много.

Если бы был Битбакет, то можно было бы вот этот плагин использовать для отображения различий в файлах: https://github.com/domclick/bpmn-diff-bitbucket-plugin

Есть еще Камундовский аналог, но по моему опыту он часто не работает.

Ща окажется что пацаны из домклика

Короче, сначала сообща обсуждаете и рисуете схему, максимально наполняете её атрибутами, мержите её в общую ветку.

Потом программисты реализуют отдельные делегаты/лиснеры и т.п п. На этом этапе имя класса конкретной реализации делегата/лиснера/и т.п. лучше поставлять руками в bpmn xml, а не в моделере. Если на этапе создания схемы вы заранее пропишете по максимуму все атрибуты и какие-нибудь заглушки вместо реализаций кода, то потом заменить их имена на настоящие имена спринг-бинов руками в bpmn xml - это вообще прям легко.

Если кто-то редактирует в моделере, другим нельзя, пока он не замержит в общую ветку.

Делайте одну ветку, частые коммиты и мержи, а в случае конфликта - реимплемент. tbd

Всем спасибо! отличная инструкция. Достойна рамки и места на стенке :)

нашел ответ - у DmnDecision есть свойство RequiredDecisions.

Да, и ещё - нужны хорошие, искренние, с любовью написанные тесты на весь процесс или иногда даже цепочку процессов/подпроцессов, если они сильно связаны.

camunda-bpm-assert