你的团队是在进行持续集成表演吗？也许你就在这个持续集成剧场里

四五年多前，我看到ThoughWorks的一篇文章提到“CI theatre「持续集成剧场」”，专门还写了一篇文章做些思考。还是当时太年轻，见识太少，若干年后被我遇到了。

什么是持续集成剧场

“CI 剧场描述了在实践持续集成 (CI) 时产生的幻觉，但实际上并没有在实践它。”

常见的故障模式包括：

• 针对共享主线运行 CI，但提交不频繁，因此集成并不是真正连续的；
• 运行测试覆盖率较差的构建；
• 使构建长时间保持红色；
• 针对功能分支运行 CI，从而实现持续隔离
• ...

现实中的持续集成表演

CI长期是红色

流水线一直在失败，无人响应，有的设置了定时任务，在相当长的周期内（超过几个月时间），一直是失败状态。这种情况一般可能如下几个原因：

• 说轻点，团队没有形成严格的构建纪律，leader不重视，交付压力没那么大，挂了就挂了
• 说重点，就是没有使用持续集成，在做“虚假表演”。

老实说，很难想象这种行为。回想我之前待过的团队（如下图所示），虽然没有这种搞笑发射器，但是一封"break build"邮件已经让研发同学”闻风丧胆“。

对于每天都会持续集成的团队（超过200人的跨地域协作），一个月里超过3次break build， 已经算是很严重的事故了。

收到"break build"邮件，开发同学会说一声“sorry”, 立刻停下手头工作，紧急修复。如果修复时长超过2个小时甚至更长，一般都会要求“rollback”。如果超过1天，一般测试就会过来问了，大家都在等着。如果超过2天，可能事情就会上升到更高级别总监角色。

另外，针对于"break build"，我们会进行分析，什么原因导致的最多？是在哪个环节出错的最多？经常出错的地方，就会公示给大家注意。

大家对于自己的代码质量是心生敬畏的，因为会影响别人的工作，以及整个团队的发布节奏。

批量自动化狂魔

现实中，有些开发人员总是喜欢炫技，动不动就API批量创建流水线，结果上千个流水线。遇到这种团队，也只能呵呵，你们牛逼。

如果你也遇到了，可以在下面留言分享你的经历。

流水线垃圾

这种情况可能比较常见，特别是使用了现成的CI/CD平台的开发团队，基本以解决当前问题为主，能实现当前的构建编译/部署就可以。

不过，容易导致A创建一个用，B也创建另外一个，某天A走了，C继续开始创建新的。 结果，就是一堆流水线垃圾，纯纯的浪费。他们不明白什么是流水线的分层分级，不知道什么是抽象复用。

如果把IT研发流水线比做汽车生产线来看待，你见过哪个汽车生产企业没事就换生产线的？

空跑表演

这种常见于会要求做构建度量的组织，为了应付度量KPI, 写个“echo ‘hello-world’“, 每天定时跑。所以，做效能度量的组织，记住“度量什么就会得到什么”。

上面这个比较极端，还有一种情况是确实在跑流水线，但是没有任何代码变更，做无效功。

养“兵”千日用”兵“一次

军队的养兵是持续加强训练，我这里提的养兵是”圈养流水线“。

与上面提到的”空跑做无效功“不同，这个又是另外一个极端。前29天不跑，第30天跑一次，靠，挂了！

这样的团队，我就想问问，你要流水线干啥，这投入产出比太低了吧。

流水线是IT研发的生命线

十几年前，老外已经告诉我们持续集成就是“产品的心脏”，你要随时监听它的跳动，它代表了产品的质量。

十几年后，AI浪潮席卷，大家都在提AI赋能，AI代码评审，AI写自动化用例，甚至有的AI分析需求等等。

可是，你的持续集成真的做好了吗？你的团队知道什么是快速反馈立即修复吗？

DevOps三部法中的反馈是核心环节，它通过监控工具快速发现问题，通过快速修复解决问题，并通过持续的反馈优化整个开发运维流程。这种快速、准确的反馈是DevOps成功的关键。 反馈的重要性

• 识别问题：通过反馈，团队能够迅速识别系统中的故障、性能瓶颈或安全隐患。
• 快速响应：反馈使得团队能够在问题发生时迅速响应，最小化对业务的影响。
• 持续改进：持续的反馈帮助团队识别改进点，不断优化开发运维流程。

反馈的实现方式

• 监控工具：使用日志、指标、事件等监控工具，实时跟踪系统状态。
• 快速修复：一旦发现问题，迅速采取行动进行修复，如回滚变更或启用/关闭功能。

反馈的优化

• 放大反馈环：增加反馈的频次和深度，更全面地了解系统状况。
• 缩短检测周期：优化监控和告警机制，加快问题发现的速度。

建立严格的团队集成纪律

每个优秀的团队都会建立严格的团队集成纪律。

• 构建失败后，不要提交新的功能代码（仅限于修复）
• 提交前，在本地运行所有的提交测试
• 等持续集成测试通过后，再继续工作
• 回家之前，构建必须处于成功状态（CI 红不过夜）
• 时刻准备着回滚到前一个版本（CI Master）
• 在回滚之前，要规定一个修复时间
• 为自己导致的问题负责

团队需要专职的人负责优化构建

前期专职人员负责团队的流水线优化，通过团队流水线模板，让全部团队成员使用

构建失败需要及时反馈

针对经常失败的步骤重点关注，通过chat工具反馈给团队。团队负责人要时刻关注构建情况。

如果近期经常构建失败，说明近期的代码提交质量出现了下降趋势，需要引起关注。

相关主题

参考

• https://www.gocd.org/2017/05/16/its-not-CI-its-CI-theatre.html
• https://gustavopinto.org/blog/continuous-integration-theater/
• https://arxiv.org/pdf/1907.01602
• https://www.thoughtworks.com/radar/techniques/ci-theatre