Version binding deployment gives users a simple and safe way to reference resources that belong together in a process solution. It unlocks low-code use-cases such as simple bundled deployments and exists as a feature in Camunda 7 (cf. learning from C7 process applications).
User Problem
Currently when working with linked resources I have only the version binding latest available as I link a form, decision, or sub-process from a BPMN process. That means whenever the engine resolves a link it will always resolve it to the latest known version.
As I maintain a larger solution I must account for compatibility of linked resources with all previously deployed process versions, a big mental load put on me as a Camunda user.
Last, latest version binding evaluates lazily, which means that on deploy time the engine does not validate the existence of a link when I deploy the process solution, but only when, i.e. activating the user task (linking a form). This means I don't get immediate feedback what works as I build my process solution.
Release Notes:
Bundled deployments through process applications or the Camunda API now have version binding. By applying the "deployment" option to a dependent BPMN, DMN, or Form file, you pin the dependency so you can deploy future versions of these files without disrupting ongoing process instances. This feature is ideal for self-contained projects without external or shared dependencies.
User Stories
Develop
[x] (M) [Configuration] When modeling a process, I can establish a link from one resource to another resource so that the link resolves to the other resource if deployed together to the engine.
[ ] (W) [Default] When linking a process to a resource within the same process application, I want the version binding to default to deployment so my deployment is more likely to work smoothly
[x] (S) [Explanation] As a user, I want to understand the version binding options so I can pick the right one
Deployment
[x] (M) [Bundling] When using a Zeebe client, I can deploy various resources (processes, forms, decisions) together as a unit (this already works).
[ ] (S) [Missing Resource] When using a Zeebe client to deploy a process and its dependent resources, the deployment fails if a dependent resource is not available
Implementation Notes
Missing Resource: The deployment should fail on unsolvable deployment bound links i.e. I have a link established but do not deploy the other resource with it.
Links to BPMN, Form, and DMN files are in scope
Exception: deployment binding for start event forms is out of scope
:robot: This issue is automatically synced from: source
Value Proposition Statement
Version binding
deploymentgives users a simple and safe way to reference resources that belong together in a process solution. It unlocks low-code use-cases such as simple bundled deployments and exists as a feature in Camunda 7 (cf. learning from C7 process applications).User Problem
Currently when working with linked resources I have only the version binding
latestavailable as I link a form, decision, or sub-process from a BPMN process. That means whenever the engine resolves a link it will always resolve it to the latest known version.As I maintain a larger solution I must account for compatibility of linked resources with all previously deployed process versions, a big mental load put on me as a Camunda user.
Last,
latestversion binding evaluates lazily, which means that on deploy time the engine does not validate the existence of a link when I deploy the process solution, but only when, i.e. activating the user task (linking a form). This means I don't get immediate feedback what works as I build my process solution.Release Notes: Bundled deployments through process applications or the Camunda API now have version binding. By applying the "deployment" option to a dependent BPMN, DMN, or Form file, you pin the dependency so you can deploy future versions of these files without disrupting ongoing process instances. This feature is ideal for self-contained projects without external or shared dependencies.
User Stories
Develop
deploymentso my deployment is more likely to work smoothlyDeployment
Implementation Notes
deploymentbinding for start event forms is out of scope:robot: This issue is automatically synced from: source