Microservice rollback approach if e2e test automation fails in CICD

7/27/2021

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

  • If yes, what happens if e2e tests fail? Is the microservice deployment rolled back?
  • Is automated rollback common in CICD in the industry right now?
  • Is there any other way to make e2e blackbox tests without deploying to Kubernetes test environment?

I could not find a good example about that?

-- gungor
automated-tests
cicd
jenkins
kubernetes
microservices

1 Answer

7/27/2021

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

Yes, you are right

If yes, what happens if e2e tests fail? Is the microservice deployment rolled 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 to Kubernetes 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.

-- Harsh Manvar
Source: StackOverflow