Всем привет! В предверии Camunda Community Summit мы открыли голосование на Camunda Community Award.
Если вам кто-то помог с Camunda, то можно смело номинировать. Больше деталей здесь: https://summit.camunda.com/community-awards/

О номинируйте меня плиз

+

А голосовалка там есть? Вроде пишут про голосование ещё

Или сами камундовские чуваки голосуют

Добрый вечер.

Хотел поинтересоваться кто как мигрирует долгие процессы?

Собственно хотелось бы иметь что-то вроде liquibase для миграций процессов, чтобы однократно запускать их автоматом после деплоя.
Но не уверен, что тулы миграции БД подойдут для этих целей.
Может быть есть какое-то более подходящее решение?

А чем не подходят встроенные механизмы Камунды для миграции экземпляров процессов (см. ссылки ниже)?

1. https://camunda.com/best-practices/understanding-process-migration/#_process_migration_defined
2. https://docs.camunda.org/manual/latest/user-guide/process-engine/process-instance-migration/

Они отлично подходят для написания самих миграций.
Собственно камундовский java api миграций и модификаций и хотелось бы использовать.
Но вопрос как потом запускать автоматом таски миграции, при этом, чтобы они выполнялись однократно на каждом окружении при старте приложения.

Например, можно использовать liquibase и CustomTaskChange для выполнения камундовских миграций.
Но в этой таске нужно уже иметь камундовский runtimeService, чтобы мигрировать процессы, но, как я понимаю, на момент, когда liquibase запускает миграции сам движок камунды еще не запущен, поэтому (скорее всего) такой вариант не очень подойдет.

когда камунда запускается у нее может быть система плагинов и там есть возможность написать код на postprocessEngineBuild

Вот орбазец как плагин создает admin user на старт rfveyls

камунды

причем делает он это после того как сама камунда создает пустую бд, таким образом можно не просто с 0 запустить, а вообще все что необходимо настроить

да, также возможно завязаться на @PostDeploy и еще видел вариант на просторах stackoverflow использовать BpmnParseListener.parseProcess()

Но чтобы миграции выполнялись однократно, надо сохранять (видимо в БД) какие мигации уже запускались.
Также надо озаботиться чтобы в кластере несколько подов параллельно не начали мигрировать.
В принципе это все реализуемо, но не хотелось бы писать свой liquibase (наверняка все уже написано до нас :) )

ну... если вы мигриуете с версии скажет 1 на версию 2, то ищите все экземпляры версии 1 и все будет норм... Что касается несколько engine... у меня какой engine создает пустую базу первый - второй выдает кучу ошибок на первый запуск.... но в конечном итоге это тоже не проблема....

Просто хотелось бы избежать, что при следующем деплое снова пытались выполниться все миграции, начиная с 1й версии

Настало ли время для офлайн митапа? Есть у кого темы, поделиться болью\похвастаться? Давайте замутим в апрелееее

Может в маааайе?

там уже миллион других крутых эвентов