automated-tests - 如何将跨微服务的端到端测试纳入多个连续交付管道中？

Question

我的团队开发了三种微服务。这三个一起提供了业务场景。他们与REST和RabbitMQ通信。看起来像Toby Clemson's presentation on Microservice Testing。

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

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

我的团队建议:

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



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

端到端阶段是瓶颈。快速的管道可能会阻碍慢速的管道，因为它会更频繁地保留端到端阶段，从而使其他管道等待测试。

一个管道中的故障将阻止其他管道的交付，也使它们无法交付紧急的错误修复程序。

该解决方案不适用于需要微服务不同组合的新业务场景。我们要么以连接所有微服务的 super 阶段结束，要么每个业务场景都将需要自己的新的端到端阶段。

端到端阶段仅显示一个狭窄的结果，因为它仅确认微服务版本的一种确切组合可以一起工作。如果生产版本包含其他版本，则不能保证它也能正常运行。

此阶段最后还与手动发布决定相冲突:如果构建端到端通过了构建，但我们决定不将其发布到生产中，该怎么办？这样，生产中将包含与端到端不同的微服务版本，从而导致扭曲的结果。

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

Answer 1

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

较长的解释:

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