如何解决CICD 端到端测试自动化失败时的微服务回滚方法
当一个微服务的新特性被合并到开发分支时,它是否总是部署到 Kubernetes 测试环境中。
- 如果是,如果 e2e 测试失败会怎样?微服务部署回滚了吗?
- 目前行业内 CICD 中的自动回滚是否普遍?
- 有没有其他方法可以在不部署到 Kubernetes 测试环境的情况下进行 e2e 黑盒测试?
我找不到一个很好的例子?
解决方法
当一个微服务的新特性被合并到开发中时 分支,是不是一直部署到Kubernetes测试环境。
是的,你是对的
如果是,如果 e2e 测试失败会怎样?是微服务部署 回滚?
由于它是一个开发环境,理想情况下运行损坏的版本应该没问题,但更多取决于您计划遵循的要求或架构。
现在行业内 CICD 自动回滚是否普遍?
是的,这很常见,但最好将其保留为手动操作,您可能会遇到想要在 e2e 失败时部署版本的情况。
手动操作 as require 的好处可能会发生变化,并且必须部署集成测试失败或其他原因的功能。
有没有其他方法可以在不部署到的情况下进行 e2e 黑盒测试 Kubernetes 测试环境?
您可以在 CI/CD、e2e 中进行子系统或小部分测试,也可以在 CI/CD 方面实现自动化并集成 Kubernetes CI 服务器可访问的 strong> 服务以进行测试。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。