Process versioning protocol?

[StephenOTT]

Description

In kogito, what is the protocol for process versioning?

Examples

1. You deploy a process and find a bug, you make a change to the BPMN and restart the app?
2. If you want to run multiple parallel versions, are these separate application deployments?
3. Other considerations?

Implementation ideas

No response

[cristianonicolai]

@StephenOTT at this stage versioning is still limited, we've got a few items in our backlog like this one https://issues.redhat.com/browse/KOGITO-6517 to start enhancing this story. In that context, the primary use case that we would like to target is that each process version would have its own deployment and so inflight processes would remain running in the service version that it started. For new versions, that would mean deploying a completely new service, that way you can simplify having to do any kind of migrations for processes.

[StephenOTT]

great. This is a very interesting conversation because there is so much pro / con:

1. There is value to have 1 app per version but they share a index
2. Having multiple versions of BPMN in a single app, leads to having deployment Apis, which leads to weird migration scenarios: where you have to migrate from v1 to v2, rather than being able to make live change.
3. Could the index service GraphQL just have a mutation that joins each of the versions data into a single table response?
4. .. others to come.

[cristianonicolai]

@StephenOTT regarding point 3, the Data Index is also a sort of Gateway API in that sense, it could act as a routing layer to redirect a mutation to start a new instance to the newest version of the process. That also means that the Data Index would keep track of the available deployments. And as for data, that's already done by Data Index, it collects data from multiple runtimes, different processes and versions as well, so it should be transparent in that sense.

[StephenOTT]

I have dealt with this A LOT in the camunda bpm space, and versioning becomes this mess for organizational deployments: where you have multiple versions being deployed, and dealing with migrations, etc. (also becomes even more complex in a dev env where you share a Data index and people are deploying hundreds or thousands of versions of a single workflow)

1. One must be able to update the current version without having to change the version ID (from the index perspective its the same version) - this would also lead to things like: should you hash the BPMN so even though its the same version ID/tag you are aware that the definition is actually different (example: you made a bug in gateway logic and only detected it post deployment into prod).

2. Migration between V1 and V2 in messy: mapping between elements, deleted elements, etc is a mess and never perfect, and full of complexity. The simpler you can keep your version protocol the better.: Codegen and service/app deployments really helps IMO which is great!

3. Starting the most recent version vs a specific version gets messy in practice and needs to be treated carefully:

   1. Deployments could be active for active instances but you want to prevent any additional instances from being created. (in some engines this is a problem, because you suspend the definition, but this breaks Async Job creation such as timers (in camunda for example).
   2. Sometimes you want to just hide the process def from users, but keep it active
   3. Sometimes you want to have multiple parallel versions active to users
   4. etc.

This last main point creates weirdness, where you know have a data index that is a index of data, but also holds additional gateway controls (which don't exist in the workflow app)?