共享预发布环境已成为云原生团队的瓶颈。新模型是在共享基础设施上支持隔离的并行测试，为每个开发人员提供个人临时沙箱，仅复制更改的服务。这提高了生产力、质量，降低了成本和运营负担。
译自：Beyond CI/CD: Why Your Infrastructure Is Your New Bottleneck
作者：Arjun Iyer
多年来，CI/CD 的承诺一直是软件交付的圣杯。我们投入了无数的时间和数百万美元来优化流水线、自动化构建，并追逐那难以捉摸的“绿色”状态。我们一直被告知，快速、高效的流水线是更快交付软件的关键。
在一段时间内，它的确奏效了。
但是，对于构建去中心化、基于微服务的软件的云原生团队来说，一个新的、潜在的问题已经出现。瓶颈不再是流水线本身，而是基础设施本身。具体来说，共享的预发布环境已成为新的瓶颈，它扼杀了发布速度，让工程师感到沮丧，并造成了一种没有人能从中获胜的“甩锅游戏”。
这不仅仅是一个小小的麻烦，而是一个根本性的扩展问题。单一、共享、长期存在的预发布环境的旧模型造成了一种零和博弈。各个团队都在不断争夺将其更改纳入一个不断崩溃的环境中，导致花费数小时试图找出是谁导致了问题。这种情况导致发布延迟，或者因为从未有过干净的测试窗口而信心不足地进行交付。一个 100 人团队的工程总监将其描述为“合并竞赛，然后是甩锅游戏”。
开发人员将大部分测试周期都花在了外部循环中，这既缓慢又乏味。内部循环测试仅限于基本的单元测试和模拟测试，而错过了集成测试反馈。
崩溃的预发布环境的隐藏成本
这种瓶颈的影响是巨大而深远的，远远超出了发布延迟。
1. 生产力损失和开发人员的挫败感
这个问题直接打击了开发人员的生产力。当开发人员完成他们的功能时，他们的工作并没有完成，只是进入了一个队列。他们无法在真实的环境中测试他们的代码，因此他们的势头停滞了。将拉取请求 (PR) 放入共享的预发布环境并获得反馈的平均时间可能会从几个小时延长到几天。
正如我之前写过的，一个崩溃的预发布环境的影响是深远的。当预发布环境不稳定时，你精心计划的发布时间表就会泡汤。没有什么比等待预发布环境可用或稳定更扼杀生产力了。
对于一个 100 人的工程团队来说，即使保守估计每个开发人员每周损失 8 个小时的生产时间，也意味着生产力损失 20%，每年转化为数百万美元的工程能力损失。AWS 记录了其开发人员体验改进如何实现了 15.9% 的同比成本降低和三年内 433% 的 ROI。持续的摩擦和对测试过程缺乏控制会削弱对系统的信任，并导致挫败感。
2. 质量妥协和风险增加
瓶颈的预发布环境会产生一种虚假的安全感。团队可能认为缓慢的手动过程可以确保质量，但事实恰恰相反。当很难进入预发布环境时，团队开始避免它或减少测试。这导致了更大、风险更高的部署，因为多个功能被捆绑在一起，几乎不可能查明错误的来源。
正如一位评论员指出的那样，单个预发布环境应该可以捕获不同应用程序无法在生产环境中和平共处的情况。但是，当它不稳定时，你无法信任测试结果，并且最终会在生产中遇到令人讨厌的意外。对于旨在独立部署的微服务来说，尤其如此。
3. 运营混乱和成本上升
这个问题不仅限于工程团队，它还造成了重大的运营负担。基础设施和 DevOps 团队不断被拉去排除故障并调试“谁破坏了预发布环境”，从而占用了战略工作的时间。环境变成了一个雪花，手动调整和配置漂移导致它慢慢地偏离生产，进一步降低了它的价值。
CircleCI 的“软件交付状态报告”发现，表现最佳的团队在 15 分钟或更短的时间内从 CI/CD 故障中恢复，而前 5% 的团队在 5 分钟内恢复。但是，由于环境管理的复杂性，大多数组织都在为更长的恢复时间而苦苦挣扎。
虽然有些人可能会建议创建更多的预发布环境，但这只会使问题成倍增加。每个新环境都需要维护、监视和数据同步，导致成本飞涨和更复杂的后勤噩梦。
平台工程的响应
业界已通过平台工程计划来应对这些挑战。Gartner 预测，到 2027 年，80% 的大型软件工程组织将建立平台工程团队，高于 2022 年的 45%。平台工程市场在 2023 年的估值为 51 亿美元，预计到 2033 年将达到 510 亿美元。
但是，实施仍然具有挑战性。“2024 年平台工程状况报告”显示，45% 的平台团队根本不衡量任何东西，而只有 22% 的团队报告说，在引入平台工程后，情况有了显著改善。
平台工程组织的社区负责人 Sam Barlien 指出：“这里反映的情况是，对于那些做得好的平台工程人员，它对他们来说非常壮观。而那些[做得不好的人]，则与壮观完全相反。人们不知道自己在做什么。”
新模型：共享基础设施上的隔离健全性
将预发布环境从单一的测试环境转变为支持开发人员的内部循环集成测试的环境。
因此，如果 CI/CD 不是问题，而复制环境也不是解决方案，那么答案是什么？
新模型是转换你现有的基础设施，以支持隔离的、并行的测试。你无需争夺单一的、整体的环境，而是为每个开发人员提供一个用于其功能的个人、临时的“沙箱”。
这并不是要复制整个堆栈。那是旧的、昂贵的模型。现代方法是一种金丝雀风格的开发人员测试。你保持一个单一的、共享的基线环境运行（你现有的预发布集群），然后，对于每个新功能，你只“复刻”正在更改的特定服务。
之前：一个单一的、脆弱的预发布环境，多个团队的更改在此处发生冲突。
之后：一个共享的预发布环境，具有智能请求路由，可以实现并行测试，而无需复制环境。
这可以通过智能请求路由来实现，通常使用服务网格。当开发人员想要测试他们的更改时，会设置一个唯一的路由键，而智能路由可确保其“沙箱”的流量转到复刻的服务，而所有其他流量继续命中稳定的基线。这允许 Dev A 测试他们的 PR，而不会受到 Dev B 工作的影响，即使他们共享相同的基础设施。
领先的组织已经在展示这种方法。DoorDash 实施了在生产环境中快速反馈循环的系统，而 Lyft 开发了复杂的控制平面来管理共享的开发环境。这些方法大大简化了微服务架构的复杂性，而无需完全复制环境的开销。
智能基础设施的变革性影响
采用这种模型可以对软件交付的各个方面带来深刻的改进：
开发人员生产力：“排队灾难”被消除。开发人员不再等待预发布环境的插槽，他们可以在编码后立即进行测试。这转化为更快的反馈循环、更少的上下文切换和更大的势头。Docker 的“2024 年应用程序开发状况报告”显示，从单体应用程序过渡到微服务架构的组织数量几乎是从微服务架构过渡到单体应用程序的组织数量的三倍，这使得这种并行测试能力更加重要。
质量：合并前测试不再局限于单元测试或模拟的依赖项。开发人员可以针对共享基线执行真实的集成和端到端 (E2E) 测试，从而在周期的早期捕获问题。这大大减少了调试“谁破坏了预发布环境”的时间，几乎为零。
成本：这种方法比复制整个环境更具成本效益。你只复制已更改的服务，共享堆栈的其余部分。这是一个可扩展的解决方案，不会以不好的方式“引起首席财务官的注意”。HashiCorp 的“云战略状况调查”发现，尽管 66% 的组织增加了基础设施投资，但仍有 91% 的组织报告说浪费了云支出。
运营简单性：管理脆弱的、始终在线的环境的运营负担大大减少。可以自动清理临时资源，因为它们与沙箱的生命周期相关联。
由更智能的基础设施模型实现的这种测试左移是释放微服务架构真正价值的关键：独立的、持续的部署。它旨在使团队能够并行工作，并以业务需求的速度移动，而不会牺牲稳定性或质量。
结论
长期以来，我们一直专注于优化软件交付生命周期的错误部分。虽然 CI/CD 至关重要，但现在是时候超越流水线，解决我们基础设施中的新瓶颈了。通过将共享的预发布环境从单租户的障碍转变为多租户的动态平台，团队可以消除摩擦，加速发布并重新获得生产力。
希望实施这种转型的组织可以探索像 Signadot 这样的解决方案，该解决方案提供 Kubernetes 原生沙箱，可以实现这种金丝雀风格的开发人员测试，而无需构建自定义基础设施路由系统的复杂性。
