Hi Team,
I have a use case where I need to perform some basic sanity tests in certain workflows before its rolled out to production. We can make use of CI/CD pipeline to trigger these tests into a separate pod for testing. But the challenge we have is with the database.
Both the production and sanity application would be pointing to the same database. How can we handle this so that the production application doesn’t get impacted with the tests going on the sanity application
There will always be some effect: If you have only one database, the load produced during the sanity check may affect your production setup. Usually, I’d recommend separate setups.
If this is not possible, consider using multi-tenancy to separate the data of the sanity checks from the production data. You can read more about it in the documentation:
Hi @StephanHaarmann ,
With multi-tenancy we will still run into issues with job executors I think.
The Sanity test application which runs in a different pod will have job executors which will process async jobs present in RU_JOB Table (common to both production and sanity application) in the database thereby processing async jobs of the production application.
How can we restrict that?
Sorry, I apparently misunderstood your question.
I don’t think it’s possible. The engine will access all jobs in the database. If you have multiple engines that use the same database, each can pick up any job. There is no build in separation.
Hello @Saju_John_Sebastian1 ,
why would both pods point to the same database? Do they have to?
Jonathan
Hi @jonathan.lukas ,
The idea was to perform basic sanity test on 1 pod (sanity) and roll over to the production pod only once the sanity is signed off as PASS.
So in this case we will need to have a separate db just for performing sanity use cases (would be costly as we will need another db). So I was thinking if at all there was any alternative approach.
Hello @Saju_John_Sebastian1 ,
would a sanity test also be possible with an in-memory database (h2)?
This would not cost you an extra db instance. In case the db behaviour is relevant, this is not possible of course.
What you could do in this case is defining a second database or schema in your production db which is used for sanity testing then.
Jonathan
Performing basic sanity tests before rolling out workflows to production is a smart approach. To address the challenge with the shared database, you can consider creating a separate schema or database instance specifically for the sanity application. This way, the tests won’t impact the production application. Additionally, you can explore using sanity test automation tools to streamline and enhance the testing process. These tools help automate repetitive tasks and ensure efficient and reliable testing.
Thanks @babyfelice .
How about the same situation in Camunda 8. Presently my management has opted to use Camunda 8 self managed.
So now I am thinking how can the same Sanity Testings be addressed in Camunda 8.
Any thoughts/suggestions