Process Model Versioning - Best Practices?

Question

Hello community,
i am wondering if anyone can share their best practices around process model versioning in yuuvis - the documentation is not very explicit on this topic unfortunately.

We only get started with process models and as of now i don´t see a straight forward way to version our models properly - the yuuvis version in question is 5.12

Let me explain the issue we are facing:
I fail to update a process model in a given model group (lets say there is a process model version change from version 1 --> 2 ) if there are still processes present of model version 1.

I do understand that we may not want to release a new process model version as long as there are processes of the former version still running. However i find that this restriction is also enforced if all processes of the latest process model version are completed or canceled.

This leaves me wondering how i am supposed to deploy a new version of a given process model - without deleting all executed processes of this process model in the first place (that is only feasible in initial development of a process - not for ongoing maintenance of an existing process modell with processes of this model already executed).

Are we supposed to create a new model group for each process model version we are releasing - it seams i am missing some important peaces.

Thanks a lot for your thoughts on this.

Best,
Clemens

Answer 1

Hello Clemens,

versioning BPM-process models is done by deploying new models in the old group. To be able to move the model in the group you must create a copy of the old model and rename it. I tend to write a model version suffix.

there are several things you should be aware of when maintaining models.
(1) Creating a new model version is not always necessary. A good rule of thumb is, that as long as you are only changing forms (including their scripts) and server-scripts you should be able to move the process model into the group while the model names match. This replaces the old model with the new one even when there are runing process instances around.
(2) When you change the name of a model and move it to the same group as the old one you effectively place them beside the old model. When you deactivate the old model and activate the new one users can only instantiate the new model.
To point your external scripts/import mechanisms to the version of the model that should cuurently be used for instantiation you should mark you new model as the standard model of the group. If you always instantiate proceses based on the standard model of the group (and you should) external michanisms to should not notice the difference (as long as you dont change the model parameters).

In development I normally use the first technique to minimise the hassle. The second one I use when i deployed a model version along the staging chain so i doint mess up the different versions.

(3) If I need to change model propeties several times without staging the intermediate models to the next staging chain link, the prior mentioned techniques doesn't work that well. In these cases (most common at the start of the modelling process) I simply delete all old processes, deactivate the current model, replace it by the new one (move over it) and activate the new one.

For the chases 1 and 3 I wrote myself a script to reduce the amount of clicking neccessary.

In my experience this way it works best.

Best regards,
Thomas

Comments

Hello Thomas,
thanks a lot for the fast and detailed response - this helped me to proceed!

Best,
Clemens