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

Question

我的团队开发了三个微服务.三者共同提供业务场景.他们与REST和RabbitMQ进行通信.看起来像Toby Clemson关于微服务测试的演讲.

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

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

我的团队建议:

我们添加了一个共享的端到端阶段,该阶段部署了所有三个微服务并对它们运行端到端测试.每当其中一条管道到达此阶段时,它就会进行部署和测试.信号量确保管道一个接一个地通过阶段.失败会停止所有三个管道.

对我而言,这似乎牺牲了微服务架构首先获得的所有独立性:

• 端到端阶段是一个瓶颈.快速管道可以阻止缓慢的管道,因为它更频繁地保留端到端阶段,使其他人在可能进行测试之前等待.

• 一个管道中的故障将阻止其他管道交付,也禁止他们运送紧急错误修复.

• 该解决方案无法适应需要不同微服务组合的新业务场景.我们最终会得到一个连接所有微服务的超级阶段,或者每个业务场景都需要自己的新的端到端阶段.

• 端到端阶段只显示了一个狭窄的结果,因为它只确认了微服务版本的一个精确组合.如果生产包含不同的版本,则不保证这也会起作用.

• 该阶段也与最终的手动发布决策相冲突:如果构建通过端到端但我们决定不将其发布到生产中会怎么样？然后,生产将包含与端到端不同的微服务版本,从而导致扭曲的结果.

那么有什么更好的方法呢？

Answer 1

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

较长的解释：

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