I am reviewing the Best Practices > Operations > Versioning process diagrams documentation page. It states the following:
As a rule of thumb, we recommend to version just the process and decision models, but not other process solution artifacts (like e.g. code classes or scripts).
Can this advice be explained in more depth? I am not fully understanding the recommendation, as it seems to me that process solution artifacts could also include codebases that hold job workers (code classes are mentioned specifically, I’m not sure under which context this is exactly referring to). From this perspective, job workers seem like an obvious solution artifact that requires versioning in the cases where job worker functionality must be upgraded alongside an new workflow version - the same thing really applies to scripts as well. This seems to be a bit contradictory - can someone elaborate?
Answering my own question as I looked right over the relevant section before posting:
As stated in the documentation:
When versioning process or decision definitions, you need to be aware that the process of course communicates with the outside world, e.g. by calling services or by using forms to collect data input from human users. All the additional artifacts needed for that might depend on the details of each other in a subtle way.
Whenever possible, we recommend that you avoid to version other artifacts beyond the process and/or decision definitions, in other words, just version ‘.bpmn’ and ‘.dmn’ files by using the default mechanism of the process engine. Embed all other artifacts (like e.g. classes, templates, scripts) into your normal application (for example a Java or Node.js application) and don’t version them.
Of course, this approach requires that you manage the subtle differences needed by running process instances of old versions. There are various options to do that. And even if some of those options discussed below might not sound ‘ideal’ from a theoretical point of view, they proved to be good enough for real life purposes and much easier to understand than complex approaches. As understandability by every team member is a very important argument, we recommend going for the approach that is as simple as possible.