#1717 - Segregate db migrations deployment - Part 1 #1932
Conversation
|
Kudos, SonarCloud Quality Gate passed!
|
Backend Unit Tests Coverage Report
|
E2E Workflow Workers Coverage Report
|
E2E Queue Consumers Coverage Report
|
E2E SIMS API Coverage Report
|
| deployCamundaDefinitions: | ||
| if: ${{ github.event.inputs.deployCamundaDefinitions == 'true' }} | ||
| name: Deploy BPMNs and DMNs to Camunda | ||
| needs: | ||
| - deploy | ||
| - deploy-sims-api |
There was a problem hiding this comment.
Should needs consider workers also?
There was a problem hiding this comment.
May be queue consumers also.
There was a problem hiding this comment.
It is a good point. Maybe we can wait for all the deployments to be successful before deploying definitions.
We can take care of it in an upcoming PR when we can also extend the conversation.
There was a problem hiding this comment.
If I am not wrong, they do not have any dependencies with any of the deployments. We can deploy it parallel if the inputs are checked. What you say?? @dheepak-aot @andrewsignori-aot @andrepestana-aot @sh16011993
There was a problem hiding this comment.
For Camunda definitions, assuming that we have a new worker task that will need an additional input parameter, the new worker app will need to be compatible with current and new versions of the bpmn, but the opposite may be not be right, when a new Camunda bpmn will not be compatible if the worker is not updated.
My point is, maybe forms can be dependent on the API, and Camunda definitions may be dependent on workers.
There was a problem hiding this comment.
Also deploying Camunda definitions could be dependent on Queue consumers, where the structure of payload to start workflow instance or something like that may have changed and could be in sync with bpmn updates.
But we can discuss this in upcoming PR.
Create a separate process to deploy the DB migrations before all the applications;
Change the applications to be built and deployed in parallel, and only if the DB migrations deployment was successful.
The github branch name is not created properly as to make the testing of deployments easy from local
Additionally added horizontalPodAutoScaler for all the applications for a max of 80 percent CPU utilization. It helps ensure that your application has enough resources to handle varying levels of workload and maintain optimal performance.
Also added distruptionBudget for minimum replica needed during updating or deleting pods. It helps ensure the high availability of your applications during maintenance activities, such as rolling updates or node evictions.
Analysis on DB migration rollback will be taken part of next PR