Use of a multi-step approach for b/g deployments in the deploy-Pipeline, which
checks out the config repo,
switches back to a version containing only changes of the Helm-values file (i.e. contains deployment changes),
applies these changes with helm upgrade,
waits for the rollout to be finished,
checks out Istio-virtual-service changes, and
apply these changes with helm upgrade
Further changes:
readiness and liveness probes are added to the deployment template
in the github-service, the order of the commits of the values and istio-virtual-service files in the config repo had to be changed.
Going forward, the configuration-changed event will contain the Git commit hashes, which have to be sequentially applied in the deploy pipeline. By this, we will also address the known limitation described in #360.
Use of a multi-step approach for b/g deployments in the deploy-Pipeline, which
Further changes:
Going forward, the configuration-changed event will contain the Git commit hashes, which have to be sequentially applied in the deploy pipeline. By this, we will also address the known limitation described in #360.