微服务架构下，传统CI/CD流水线成为瓶颈。应重新定义流水线职责，专注于组件级验证，将系统范围测试转移到开发者金丝雀测试，以解决Staging瓶颈问题，提升开发效率和信心。
译自：Your CI/CD Pipeline Wasn't Built for Microservices
作者：Arjun Iyer
对于任何认真对待微服务的组织来说，传统的 CI/CD 流水线已经成为一种负担。 它是减缓开发人员速度，扼杀你试图实现的敏捷性的最大单一来源。
这与工具无关。 Jenkins、GitLab、GitHub Actions 和 CircleCI 都是强大的工程工具。 问题在于我们强加给它们的过时的、单体式的理念。 我们已经习惯于将流水线视为最终的、全知的质量守门员。 我们给它增加了一个庞大的、多阶段的“集成测试”阶段，试图针对整个分布式系统验证每个变更。
在微服务的世界中，这是一个徒劳的尝试。 它迫使每个开发人员进入可怕的“Staging 瓶颈”——一个缓慢、脆弱且持续争用的环境，信心在这里消亡。 流水线本应是速度的引擎，却已成为缓慢的象征。
百万美元的瓶颈
这种摩擦的代价是惊人的。 当一个共享的 Staging 环境为数十或数百名工程师提供服务时，它就会变成公地悲剧。 开发人员 A 推送了一项更改，导致开发人员 B 的测试失败。测试数据被破坏。 团队排队等候数小时，以获得“稳定”的窗口来验证简单的更改。
这不仅仅令人沮丧。 这直接打击了利润。 Forrester 最近的一份关于开发者体验的报告发现，74% 的受访者认为改善 DevEx 可以提高生产力。 当你最昂贵的人才花费数小时与损坏的测试环境作斗争时，这不仅仅是一个士气问题， 这是一个百万美元的生产力问题。
正如微服务先驱 Sam Newman 所说，微服务的承诺是“独立的可部署性”。 然而，我们的测试实践将所有服务链接在一起，迫使它们进入单体式的发布过程。
重新定义工作，而不仅仅是优化工具
突破不是构建“更好”的流水线； 而是从根本上重新定义其工作描述。 如果传统的“测试”阶段是痛苦的根源，那么我们必须从流水线的核心职责中将其外科手术式地移除，并将这项工作交给更出色的现代替代品。
这创造了一种新的、更有效的分工。 流水线被解放了。 它的作用缩小到它最擅长的：闪电般快速的本地验证。 它应该运行单元测试、执行静态分析、检查 API 契约并构建可部署的工件。 它的全部工作应该在几分钟内完成。 它不再回答复杂的问题“此更改是否与我们系统的其余部分一起工作？” 它只是简单地回答“这是一个格式良好、高质量的组件，可以进行验证吗？”
现在，系统范围验证的关键问题有了一个新的归宿。 这就是“开发者金丝雀测试”的用武之地。 它是为分布式系统的现实而设计的，是已损坏的“集成测试”阶段的现代继承者。
多租户环境中的开发者金丝雀测试
开发者金丝雀测试不是在混乱的共享环境中触发流水线测试，而是在单个高保真预生产环境中，以完美的隔离进行大规模的并发验证。 它将你的 Staging 环境从战场转变为可扩展的多租户平台。
工作流程代表了我们需要的演变。 开发人员的精益 CI 流水线成功地从功能分支构建了该服务的新版本。 为了对其进行验证，该服务的“开发者金丝雀”被部署到高保真 Staging 环境中。 它与所有其他服务的稳定基线版本一起运行。
开发人员启动端到端测试。 此测试请求标有唯一的上下文标头。 智能路由层（通常是服务网格）会检查流量。 它将带有开发人员标头的任何请求定向到他们的金丝雀。 所有其他开发人员的测试请求都标有他们自己唯一的上下文，并被路由到他们各自的金丝雀。 任何未标记的流量都只会访问稳定的基线服务。
结果是完美隔离的测试运行，它针对完整的、真实的环境（包括其实际依赖项）验证新代码，而没有任何冲突或干扰的风险。
Matthew Skelton 和 Manuel Pais 在他们的著作“团队拓扑”中称这种方法直接解决了“认知负荷”问题。 通过提供一种简单、抽象的测试方法，平台团队可以减少开发人员的额外认知负荷，使他们能够专注于交付价值。
回报：信心和速度，重新统一
通过采用此模型，你可以修复已损坏的范例。 CI/CD 流水线成为代码集成的精益、快速引擎，而集成测试的复杂任务则转移到为分布式系统构建的框架。
信息很明确：不要因为 CI/CD 工具速度慢而责怪它们。 而是改变它们的工作。 让你的流水线专注于组件级验证，并将系统范围的测试转移到开发者金丝雀测试。 这就是你打破瓶颈并释放微服务真正潜力的方式。
