CICD 端到端测试自动化失败时的微服务回滚方法

Question

当一个微服务的新特性被合并到开发分支时，它是否总是部署到 Kubernetes 测试环境中。

• 如果是，如果 e2e 测试失败会怎样？ 微服务部署回滚了吗？
• 现在行业内CICD自动回滚常见吗？
• 有没有其他方法可以在不部署到 Kubernetes 测试环境的情况下进行 e2e 黑盒测试？

我找不到一个很好的例子？

Answer 1

当一个微服务的新特性被合并到开发分支时，它是否总是部署到 Kubernetes 测试环境中。

是的，你是对的

如果是，如果 e2e 测试失败会怎样？ 微服务部署回滚了吗？

由于理想情况下它是一个开发环境，因此运行损坏的版本应该没问题，但更多地取决于您计划遵循的要求或架构。

现在行业内CICD自动回滚常见吗？

是的，这很常见，但是最好将其保留为手动操作，您可能会遇到想要在 e2e 失败时部署版本的情况。

根据需要手动操作的好处可能会发生变化，并且必须部署集成测试失败或其他原因的功能。

有没有其他方法可以在不部署到 Kubernetes 测试环境的情况下进行 e2e 黑盒测试？

您可以在 CI/CD 中进行子系统或小部分测试， e2e也可以在CI/CD端自动化并集成可访问CI服务器的Kubernetes服务进行测试。