在不久之前的一篇文章中，我讲到自己上半年最重要的工作是完成了一个持续集成 (CI) 监控平台的开发。文章发出来之后，不少同学私信与我联系，问的最多的一个问题就是这个 CI 监控平台到底在监控什么。今天就和大家聊聊这个话题。

CI 是一个不间断运行的系统。这个系统持续产生大量数据。对 CI 系统的监控，一定不是"胡子眉毛一把抓"，而是"有所为有所不为"。

那些对研发团队有帮助，对 CI 工作改进有意义的数据，才是我们需要重点监控的。在我看来，这些数据包括但不限于以下方面。

CI 稳定性数据。稳定性是 CI 第一位的事情。对于开发者来说，他们最关心的就是 CI 有没有中断，是不是稳定。CI 中断意味着 CI 失败率 100%，团队研发工作彻底停摆。

实时的 CI 中断状态，决定了开发者能否提交代码；历史的 CI 中断次数，中断时间，中断部位等统计数据，能够帮助我们客观识别 CI 的薄弱环节，并对症下药予以改进。

100% 失败率的 CI 是停摆的。100% 成功率的 CI 也没有实际意义。实际情况通常介于二者之间，即 CI*概率性失败*。由当前代码改动导致的 CI 失败，是可以接受的，也正是 CI 存在的意义。

然而，与当前代码改动无关的 CI 失败，却是我们需要留心的，因为它直接影响开发者体验和 CI 公信力。一般来说，真正会产生 CI 失败的代码改动是很少数的。CI 的成功率数据，能够一定程度上反映 CI 是否稳定，我们需要监控它。

具体的 CI 不稳定因素，则可以通过统计主干上的 CI 失败情况 (失败环节，失败用例，错误消息等) 来大致识别。了解 CI 实时的成功率和当前已知的不稳定因素，对于开发者提交代码和分析 CI 失败是有帮助的。

CI 效率数据。"天下武功，唯快不破"。对于 CI，尤其如此。对于开发者来说，有两个数据很重要，一是在 pre-merge CI 阶段，从触发 CI 任务到获得 CI 结果的时间；二是在 post-merge CI 阶段，从代码改动合入主干到最后出包的时间。

我们需要监控这些数据。进一步，CI 各个任务和阶段的执行时间，以及等待特定资源所消耗的时间，通常也是需要我们监控的。

CI 质量数据。CI 的中心任务是通过多个环节的检查和测试，在代码提交阶段尽可能发现更多软件缺陷。CI 的质量，反映的是 CI 是真的能够发现代码改动带来的缺陷，还是仅仅在空转。如何度量 CI 质量是一个见仁见智的话题。

在我看来，CI 各个测试环节的覆盖率数据，是反映 CI 质量的重要方面。这里的覆盖率主要是代码覆盖率，其次是需求覆盖率和缺陷覆盖率。通过监控测试覆盖率数据，我们能够了解 CI 各个测试阶段的有效性，以及识别没有或很少被覆盖的代码区域，并有针对性地改进。

研发效能数据。除了 CI 自身的稳定性，效率和质量数据之外，研发团队的相关数据也是我们可以监控的。这方面数据可以有很多，举例如下。

代码提交数据：监控每一个合入的代码改动数据，包括改动类型，提交者，合入时间等。基于时间维度进行统计，可以了解团队给定时间内的总体工作量；依据开发者维度进行统计，可以识别活跃的开发者。分析代码提交时间，甚至能够从侧面反映大家的加班情况。

代码评审数据：监控代码评审系统上的评论数据，包括评审者 (Reviewer)，被评审者，代码改动链接等。基于这些数据，可以统计项目代码评审情况，例如总的评论数量，零评论的代码改动占比等，也可以识别出对团队贡献较大的活跃评审者。

以上就是个人认为的 CI 监控平台需要重点关注的数据。需要强调的是，数据监控不是我们的目的，利用监控到的数据改进工作才是我们的目的。并且，工作是否真正得到改进，还需要基于后续监控的数据进行客观评判。

感谢大家的阅读！另外，想看一些测试开发，持续集成，Python 编程等领域原创文章的同学，欢迎关注我的个人公众号测试不将就或同名博客，谢谢。