和传统的集成方式相比，持续集成可以有效地缩短反馈周期、提高软件质量、降低开发成本。但它并不能做到完美，总是会有新的问题出现。如何改进遗留系统的流水线问题，你是怎么想的？

　　写在前面

持续集成（Continuous Integration）是一种软件开发实践，它倡导开发团队频繁地进行系统集成，每一次的集成都可以通过流水线（Pipeline）快速验证。和传统的集成方式相比，持续集成可以有效地缩短反馈周期、提高软件质量、降低开发成本。这种开发实践也越来越为更多的开发者所接受。对于一个有七年历史的项目，非常幸运的是我们在项目刚开始就使用了持续集成，这也是我们可以长期、稳定地给客户交付高质量软件的保障之一，但是有时我们在项目中也经常会听到一些这样的声音：

每次想提交代码的时候都没有机会， 我们是不是要考虑引入提交“令牌”机制，拥有“令牌”的人才能提交

这个Pipeline已经挂了这么久了，今天估计是无包可测了

这个是测试“随机挂”，重新触发一下Pipeline就好了

我的提交Break了Pipeline了吗？我确认一下

….

通过分析我们发现，这些声音背后的真相更是残酷：

约20对Pair依赖的核心Pipeline构建时间超过1个小时，开发的反馈周期长，大量的半成品积累在本地开发环境和Pipeline上

代码提交之后大约需要2个小时才能出包，每周平均每天可供QA测试的包数量不足1个，平均每个Story的周期时间长

上线前冻结代码、回归测试的时间大约需要2周左右，冻结期间产生的代码无法集成、验证

Pipeline不稳定测试导致某些Pipeline构建至少需要重新触发2到3次左右

依赖关系复杂，牵一发而动全身，优化不知从何做起

有时“正确地做事情”比“做正确的事情”还要困难，在项目一开始便在项目中尝试实施TDD等敏捷开发实践，但是随着项目的规模的增加，功能越来越丰富，单元测试在增加、基于UI的功能性测试也在增加，流水线的构建速度却变得越来越慢。微服务架构具有易扩展，技术选择灵活和部署独立等特性，于是我们把应用拆分为不同的微服务，但是同时也带来了流水线的数量和微服务之间集成测试的增加，Pipeline的依赖关系也变得越来越复杂。

在去年，项目中的DevOps小组，在前人的基础上和团队便大刀阔斧地开始了Pipeline的改进工作，希望可以通过一些必要的措施，优化流水线，保证QA每天有包可测、缩短开发期间的反馈周期。

　　改进什么？

这是我们在改进刚开始就面临的一个问题，本地Pipeline数量众多，每一个Pipeline平均有3-4个构建阶段，每一个阶段又有2-3个并行执行的任务，如此众多的Pipeline和任务，应该从什么地方着手？面对Pipeline构建时间长、测试不稳定、代码冻结时间长，依赖关系复杂等问题，应该如何决定改进的优先级？

根据高德拉特的约束理论（ToC），所有在非约束点的改进都是假象，我们可以把整个构建流水线看作是一个完整的系统，如果我们改进的是约束点的上游，就会增加约束点的负担；如果我们改进的是约束点的下游，由于通过下游的工作量主要由约束点决定，所以任何在这个位置的改进都是徒劳无获，无益于整个系统产出的提高还造成了浪费。

现状问题树是寻找约束点的方法之一，借助于这个思维过程（Thinking Process）可以帮助我们梳理“不良效果”（Undesirable Effects ）之前的因果关系，atv，最后找到需要解决的核心问题，解决了根本问题之后，由其衍生的各种“不良效果”也大多会消失。通过内部的讨论和演练，我们最终把问题定位在以下几个方面：

核心Pipeline构建时间过长

集成环境测试成功率低

缺少必要的监控预警机制

　　如何改进？

　　降低资源的占用时间

在零件制造车间中，每一个零件都需要按照既定工序通过车、镗、铣、磨、刨等车床，每一个阶段都需要占用车床资源进行特定的加工工作。和零件加工类似，来自客户的每一个功能性需求也同样要经过类似处理流程，从需求分析到编码开发，从构建打包到部署测试，每一个环节都需要占用一定的资源。如果在单位时间内，资源占用的比率越高，就会产生比较严重的排队现象。如下图所示，在单位时间内如果资源占用大于百分之七十，队列的长度也会呈指数型增长。