ZeebClient is deploying new version without change

Camunda 8 Topics Discussion & Questions
, , ,
1

HI Camunda Team,
I am using 8.2 for now and we were using @Deployment for deploying the BPMNs and it only deployed when there was any change in bpmn…Now we have a requirement to deploy manually so we starte using zeebeClient.newDeployResourceCommand()
.addResourceFromClasspath(bpmn.getFilename())
.send()
.join();

But now what is happening is even if there is no change in bpmn, it deploys a new version…this is causing issue in prod…any fix for this?

2

Hi @Bittu ,

When switching from @Deployment in Spring Zeebe to manual deployment using zeebeClient.newDeployResourceCommand(),

Here’s what’s happening:

Why zeebeClient.newDeployResourceCommand() Deploys a New Version Every Time

Zeebe always creates a new process definition version when:

  • You deploy a BPMN file even if the content hasn’t changed.

Unlike the @Deployment annotation (Spring Zeebe), which:

  • Hashes the BPMN file and skips deployment if the file hasn’t changed.

zeebeClient.newDeployResourceCommand() does not do any diffing or caching — it blindly creates a new version each time you call it.

Your Options to Prevent Redundant Deployments

Option 1: Manually hash and compare before deploying

You can manually compute a hash (like SHA-256) of the BPMN content and store the hash somewhere (DB, file, or Zeebe variable), then compare before deploying:

import java.nio.charset.StandardCharsets;
import java.security.MessageDigest;
import java.util.HexFormat;

public String calculateBpmnHash(String bpmnXml) {
    try {
        MessageDigest digest = MessageDigest.getInstance("SHA-256");
        byte[] hashBytes = digest.digest(bpmnXml.getBytes(StandardCharsets.UTF_8));
        return HexFormat.of().formatHex(hashBytes);
    } catch (Exception e) {
        throw new RuntimeException("Hashing failed", e);
    }
}

Then:

  1. Read BPMN XML as string.
  2. Calculate hash.
  3. Compare with stored hash of last deployed version.
  4. Only deploy if hashes differ.

Option 2: Use the same logic from Spring’s @Deployment

The @Deployment logic in spring-zeebe does exactly this hash-checking. You can replicate that behavior or switch back to it for environments like staging.

Relevant source:
https://github.com/camunda-community-hub/spring-zeebe

You could also read through the logic and wrap your zeebeClient.newDeployResourceCommand() calls with the same hash-check mechanism.

Option 3: Check existing deployed versions

You can list the latest deployed versions and compare the resource content before deploying. However, this is not officially supported via Java client yet, unless you store metadata alongside deployments.

A workaround here is to add a checksum in a custom BPMN extension or as a deployment variable.

Best Practice Summary

If you’re managing deployment yourself:

  • Hash the BPMN content before deploy.
  • Store/check hash in a reliable store (e.g., a config DB or file).
  • Only deploy when hash changes.

This gives you full control and avoids cluttering Zeebe with redundant versions.