Microservice rollback approach if e2e test automation fails in CICD Microservice rollback approach if e2e test automation fails in CICD kubernetes kubernetes

Microservice rollback approach if e2e test automation fails in CICD


When a new feature of a microservice is merged into developmentbranch, is it always deployed to Kubernetes test environment.

Yes, you are right

If yes, what happens if e2e tests fail? Is the microservice deploymentrolled back?

Since it's a development environment ideally it should be fine to run the broken version however more depends on the requirements or architecture you are planning to follow.

Is automated rollback common in CICD in the industry right now?

Yes, that's common however it would be better to keep it as Manual action, you might have a scenario where you want to deploy the version while e2e failing.

The benefit of Manual action as require might get change and have to deploy feature in which integration testing failing or something else.

Is there any other way to make e2e blackbox tests without deploying toKubernetes test environment?

You can do the subsystem or small portion testing in CI/CD, e2e also you can automate on CI/CD side and integrate the Kubernetes service accessible to the CI server for testing.