Why？

Pipeline 的速度会随着工程的变大而逐渐变慢，如果 pipeline 的反馈时间太长。则会影响工程师的使用热情，工程师会倾向于跳过 pipeline 中的部分质量相关步骤，甚至全部步骤，这样的话，CI 上的质量防线就会形同虚设了。
因此，控制 Pipeline 的执行时间在一个合理的范围内，是一个非常重要的事。

How？

• 建立一个标准和度量系统：还是那句说了一万遍的话 “无法度量就无法改进”。度量什么呢？ pipeline 每个阶段花费的时间，一般会分为：静态代码扫描的时间，单元测试执行时间，其它自动化测试执行时间，构建时间，发布时间。每一段的执行时间其实都可以通过某种形式得到，然后汇总到一起，形成报表。每个阶段的时间进行分级，如：优秀，可接受，不可接受。对于不同级别给与不同的处理方式。
• 能力基线：约定一个组织级的能力基线，所有团队的能力都应该在这个基线以上，如果不达标，必须改进。 例如：约定项目单测阶段时间不超过 5 分钟，如果超过了需要做整改。基线不能定得太狠，需要让团队付出一些努力后，就可以达到，可以分一两个季度来爬坡，每半年 review 一下，确定是否提升一次基线要求。
• 让开发人员、QA、团队负责人低成本、高频率的获得这样的度量信息。 如：突破门限会自动收到报警邮件，不同角色邮件每日收到分级的报表，使用 IM 的 hook 推送消息到应用的所有者等。
• Pipeline 标准的建立：很多不正确的实践会让 pipeline 的性能很糟糕，这部分问题往往非常好改，同类技术栈，大家遵照一个标准去配置就好了。这里的标准应该是按照最佳实践来涉及的，能够有效降低实施成本，减少走弯路。
• 习惯的养成：确保团队把关注 pipeline 的健康变为日常工作的一部分，有问题及时解决（这是个不容易的工作）。

Tips

• 单元测试执行慢是 pipeline 慢的主因之一，常见原因有：

  • 不是真正的单元测试。外部资源没有 mock，导致执行缓慢。这些用例一定要修改。
  • 部分长尾用例，需要调优。 一般单个单元测试执行时间非常快，0.1 秒以内是正常的。如果碰到数秒，或者数十秒的用例，需要做调优，调优一般很好做。
  • 采用并行执行的技术。拿 Java 下的 Junit 框架来说。4.7+surefire2.16 以后支持 Maven 并行触发,5.3 以后支持原生触发 TestNG 也有并发执行的选项。如果设置得当，我的经验数据是会快 30% 以上，甚至更多。 并行技术的一个前提是，单测之间是没有耦合关系的，不会因为执行顺序的不同而得到不同的结果（这是很多写单测的同学特别容易犯的毛病）

• 构建慢：

  • 在本地，或者部分 CI 阶段采取增量构建，而不是全量构建的方式。
  • 花时间深入研究构建的步骤和方法，压榨潜力，如：采用多核技术，合理的多线程设置，合理的参数设置看这个例子，采用分布式并行构建
  • 是否工程本身不合理？需要拆分？
  • pipeline 里是否存在不必要的重复构建？
  • 每一种技术栈也就那么几个套路，读一下这篇文章，感受一下。
  • 善用一些工具，可以帮助你事半功倍，看这个例子

• 提倡在本地搞定再上 CI

  • 随意提交 CI 是浪费公共资源。这个概念需要传达到每个开发人员的
  • 本地静态代码扫描、单元测试、其它测试全部跑过以后，上 CI 就不会有 pipeline 折了，远程调试痛苦的事情了。
  • 本地配置应该和 CI 服务端的配置一致，这样能够省很多功夫。