如何将跨微服务的端到端测试包括到多个连续交付管道中？

Question

我的团队开发了三种微型服务。这三者一起工作，提供了一个业务场景。他们与REST和RabbitMQ通信。看上去像在托比·克莱姆森关于微服务测试的介绍里。

每个微型服务都有自己的连续输送管道。它们是交付，而不是部署管道，这意味着最终会有一个手动发布决定。

如何将业务场景的端到端测试(即跨所有微服务)包含到交付管道中？

我的团队提出这样的建议：

我们增加了一个共享的端到端阶段，部署了所有三个微服务，并对它们进行端到端测试。每当其中一条管道达到这个阶段，它就会进行部署和测试。信号量确保管道通过一个接一个的阶段。故障使三条管道全部停止。

​

​

在我看来，这似乎牺牲了微服务体系结构首先赢得的所有独立性：

• 端到端阶段是一个瓶颈。一条快速的管道可能会阻碍缓慢的管道，因为它会更频繁地保留端到端阶段，让其他管道在运行测试之前等待。
• 一个管道的故障会阻止另一个管道的传递，也会使它们无法发送紧急的错误修复程序。
• 该解决方案不适合需要不同的微服务组合的新业务场景。我们要么以连接所有微服务的超级阶段结束，要么每个业务场景都需要自己的、新的端到端阶段。
• 端到端阶段只显示出一个狭窄的结果，因为它只确认了一个微服务版本的精确组合一起工作。如果生产包含不同的版本，它不能保证这也能正常工作。
• 这个阶段也与最终的手工发布决定相冲突:如果一个构建通过了端到端，但是我们决定不将它发布到生产中呢？然后，生产将包含不同于端到端的微服务版本，从而导致扭曲的结果。

，那么有什么更好的方法来做这件事呢？

Answer 1

简而言之，这样的集成测试不是微服务开发/部署团队和流程的一部分，而是一个有自己的流程的单独团队。您可以在该团队中尽可能多地自动化，但最终您需要决定是否发布。

更详细的解释是：

Microservices架构风格的发明是为了帮助大型组织管理大型应用程序，并避免团队之间通信和依赖的开销。因此，如果你想遵循这种风格，你真的应该有3个独立的团队-每个服务一个。每个团队都将在各自服务的整个生命周期中承担全部责任。现在，当您想要进行端到端测试(通常称为集成测试)时，您将建立一个负责这些测试的第四个团队。您将有一个人作为负责的发布管理人员，他拥有一个分阶段/测试集群，并决定何时测试足以将一个新版本的服务发布到野外。您的目标应该是尽可能地使团队在其服务的依赖关系和发布周期方面解耦。如果您希望服务团队完全独立，您还可以使集成测试成为每个团队的一部分。这意味着每个团队都有测试/暂存集群，每个团队中都有一个负责任的测试/发布管理器角色。