如何将跨微服务的端到端测试包含到多个持续交付管道中? [英] How do I include end-to-end tests across microservices into multiple continuous delivery pipelines?
问题描述
我的团队开发了三个微服务.三者协同工作以提供业务场景.它们与 REST 和 RabbitMQ 进行通信.看起来像
对我来说，这似乎牺牲了微服务架构首先赢得的所有独立性:
端到端阶段是一个瓶颈.快速流水线可以阻止慢速流水线，因为它更频繁地保留端到端阶段，使其他流水线在运行测试之前等待.
一个管道出现故障会阻止其他管道交付，同时也会导致它们无法交付紧急错误修复.
该解决方案不适应需要不同微服务组合的新业务场景.我们要么最终得到一个连接所有微服务的超级阶段，要么每个业务场景都需要自己的新端到端阶段.
端到端阶段只显示了一个狭窄的结果，因为它只确认一个精确的微服务版本组合可以一起工作.如果生产包含不同的版本，则不保证这也能正常工作.
该阶段也与最终的手动发布决定相冲突:如果构建通过端到端但我们决定不将其发布到生产环境怎么办?然后，生产环境将包含与端到端不同版本的微服务，从而导致结果扭曲.
那么有什么更好的方法来做到这一点?
简而言之 - 这样的集成测试不会成为微服务开发/部署团队和流程的一部分，而是一个拥有自己流程的独立团队.您可以在该团队中尽可能地自动化，但最终您需要决定是否发布.
更长的解释:
发明微服务架构风格是为了帮助大型组织管理大型应用程序并避免团队之间的通信开销和依赖关系.所以如果你想遵循这种风格，你真的应该有 3 个独立的团队——每个服务一个.这些团队中的每一个都将对各自服务的整个生命周期负有全部责任.现在，当您想要进行端到端测试(通常称为集成测试)时，您将建立一个负责这些测试的第四团队.您将拥有一个负责的发布经理，他拥有一个登台/测试集群，并决定何时测试证明足以将新版本的服务发布到野外.您的目标应该是尽可能地在服务的依赖关系和发布周期方面解耦团队.如果您希望服务团队完全独立，您还可以将集成测试作为每个团队的一部分.这意味着每个团队都有测试/登台集群，并且每个团队都有一个负责任的测试/发布经理角色.
My team develops three microservices. The three work together to provide a business scenario. They communicate with REST and RabbitMQ. Looks like in Toby Clemson's presentation on Microservice Testing.
Each microservice has its own continuous delivery pipeline. They are delivery, not deployment pipelines, meaning there is a manual release decision at the end.
How do I include an end-to-end test for the business scenario, i.e. across all microservices, into the delivery pipelines?
My team suggested this:
We add one shared end-to-end stage that deploys all three microservices and runs the end-to-end test on them. Each time one of the pipelines reaches this stage, it deploys and tests. A semaphore ensures the pipelines pass the stage one after the other. Failure stops all three pipelines.
To me, this seems to sacrifice all the independence the microservice architecture wins in the first place:
The end-to-end stage is a bottleneck. A fast pipeline could thwart slow pipelines because it reserves the end-to-end stage more often, making the others wait before they may run their tests.
Failure in one pipeline would stop the other pipelines from delivering, also disabling them from shipping urgent bug fixes.
The solution doesn't adapt to new business scenarios that need different combinations of microservices. We would either end up with a super-stage that wires all microservices, or each business scenario would require its own, new end-to-end stage.
The end-to-end stage shows only a narrow result because it confirms only that one exact combination of microservice versions work together. If production contains different versions, it does not guarantee this will work as well.
The stage is also in conflict with the manual release decision at the end: What if a build passed end-to-end but we decide to not release it to production? Production would then contain a different version of that microservice than end-to-end, causing warped results.
So what's a better way to do this?
In short - Such an integration testing would not be part of the microservices development/deployement team and process, but a separate team having its own process. You can automate as much as possible in that team, but in the end you need a decision whether to release or not.
The longer explanation:
The Microservices architectural style was invented to help large organizations to manage large applications and avoiding overhead of communication and dependencies between teams. So if you want to follow this style, you should really have 3 independent teams - One for each service. Each of those teams would have complete responsibility over the whole life-cycle of their respective service. Now when you want to do end-to-end testing (often called integration testing) you would set up a 4th team that is responsible for those tests. And you would have one person being the responsible release manager who owns a staging/testing cluster and decides on when testing proves sufficiently to release a new version of a service into the wild. Your goal should be to decouple the teams as much as possible in terms of dependencies and release cycles of their services. If you want complete independence of the services teams you can also make the integration testing part of each team. Meaning you have testing/staging cluster for each team and a responsible testing/release manager role in each team.
这篇关于如何将跨微服务的端到端测试包含到多个持续交付管道中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
