Question about process versioning , deployment, and its behaviour for cluster deployment with shared Camunda database

Dear Team,

I have question about the topic with regard to deployment of clustered of microservices with embedded Camunda using spring boot and particularly in the context of ramp-up deployment and rollback scenario, all of them refer to shared Camunda database.

I have been following documentation and this forum for issues so far regarding my usage and deployment. But there are still doubts which I think better clarify here to confirm my understanding and my usage if they are proper.

For initial deployment, when process instances are not yet created from process definition. We can use non deployment aware and this , I believe this per documentation, is considered Homogenous cluster env.

However, given typical evolution of microservices and its deployment when there is ramp-up deployment (say 2%, 10% and eventually 100% ) and when process instances are actively created.
I have observed ClassNotFoundException when new deployment of microservices are not fully ramped up to 100% and old instance of microservices surprisingly handle process instances created from new instances while they are in midst of deployment.

In scenario describe, is it correct to say we should away use deployment aware for typical usage of Camunda since process definition may also evolve and handling of ramp-up deployment scenario ?
Is it correct that one should always perform versioning of process application to create isolation / boundary for deployment aware job executor ?

Are there any other ways or work around to handle this without create process versioning that I might not be aware of ?

Also, in our env, sometimes any deployment of microservices can be rolled back to previous docker image when there are issues with microservices codes, if without resorting to deployment aware and process versioning , are there any other ways to handle ClassNotFoundException ? so we may have deployment 1, (for easy quote, d1) and subsequent with every deployment , there are changes to the same BPM process definition files, so we have d1, d2, d3, d4… etc
In the rollback scenario, Is Camunda able to detect that d1, d2 / d3 has been deployed previously ? say, in the environment where folks accidentally perform d1 but latest process definition should be of d3 / d4 ? How should we better handle this without causing issue to the shared database ?

Looking forward to your reply,

Thanks & Regards,
abarita

anyone can help on this ?