研发效能 保证 PiPeline 的执行速度健康

刘晓光 · 2020年03月30日 · 最后由 槽神 回复于 2020年03月30日 · 903 次阅读

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 服务端的配置一致,这样能够省很多功夫。
共收到 1 条回复 时间 点赞

度量是一把利器,善用度量,能为团队挖出很多可改进点

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册