通常，CI（持续集成）的重点涵盖从代码提交到测试环境，CD（持续交付）涵盖到向最终用户的实际交付。有许多文章描述 DevOps 的指标，Pipeline的指标，这些指标往往对于CD有很好的覆盖，但很少有文章专门讲述CI的指标 。因此本文试图说明CI的指标，下面是CI关键指标表。
| 指标名称 | 说明 |
| 持续集成频率 | 在一个月或一周内进行了多少次 CI？ |
| 持续集成成功率 | 持续集成成功次数对比总次数 |
| 最长失败持续时间 | 从一个 CI 失败到恢复通过，在观察期中最长的时间是多少？ |
| 平均持续集成执行时间 | CI 平均执行多长时间 |
| 测试用例数量 | CI 中的测试用例总数 |
01
—
持续集成频率
持续集成频率是反映团队DevOps 实践深度的最明显指标，频率越高，效果越好。
例子：在 2020 年 10 月，jenkins 的 CI 作业运行 55 个生成，因此每月 CI 频率在 2020 年 10 月为 55，无论失败或成功
关于不同的CI
一个团队可能有一些用于不同目的的 CI（比如不同的Jenkins Job）。CI频率指标需要只反映最经常执行的CI作业，无需收集多个CI作业统计信息进行组合。
对于不同的观测周期
通常，有两个周期，一周和一个月。每周 CI 频率指导每周工作，每月一次。
CI数据样例
| 周 | 频率 | 成功次数 | 成功率 | 最长失败持续时间（分钟） | 平均执行时间(分钟) |
W21 | 12 | 7 | 58.3% | 61 | 15.4 |
W22 | 16 | 10 | 62.5% | 53 | 10.4 |
W23 | 24 | 20 | 83.3% | 55 | 6.2 |
W24 | 18 | 15 | 83.3% | 45 | 7.5 |
W25 | 34 | 30 | 88.2% | 30 | 3.5 |
CI频率每周柱状图
02
—
持续集成成功率
CI成功率反映了CI的质量，但100%的成功率不是最好的数字，因为100%的成功率意味着人们花费了额外的准备工作量以达到100%成功率，而没有充分利用CI机器，这是没有必要的。
例子
在第 23 周，有 24 个 CI 生成，其中 20 个 CI 生成成功，因此该周的 CI 成功率为 83.3%（从 20/24 开始）
关于不同的CI
最重要的CI成功率也是最高频的CI，其他 CI也需要观测成功率。
不同观测周期的 CI 成功率
此方面与上述 CI 频率相同，通常、每周和每月观察。
图表示例
03
—
最长失败持续时间
最长的失败持续时间反映了团队响应CI的速度，越快越好。
例子
某次CI之前，CI是成功的，但这次运行失败，下一次成功生成发生在2小时之后，那么这失败持续时间为2h，120分钟。如果在观察期间，120 分钟是最长的失败持续时间，则该期间最长的失败持续时间为 120 分钟。
关于不同的CI
最重要的 最长失败持续时间也是在最高频的 CI之上，其他 CI也需要观察
对于不同的观测周期
与其他指标一起采取相同的观察期。
图表示例
04
—
平均持续集成执行时间
一个 CI 作业的时间是 CI 执行时间，即从触发器到完成的时间。如果持续时间较短，CI 的反馈将更快得到。平均 持续集成执行时间可以显示 CI 的效率。
例子
当CI被触发开始，直到执行完成，它运行了10分钟，多次CI执行后，得到执行时间的平均值，分钟是其常见的单位。
不同CI 作业的执行时间
最重要的 CI 执行时间也是在最高频的 CI 作业上。但其他 CI 作业也需要执行时间观测。最高频的CI 作业一般在工作时间运行，因此执行时间对日内工作有显著影响。如果一个 CI 作业是在晚上运行，那么执行时间在没有超过一晚上之前，不敏感。
对于不同的观测周期
与其他指标一起采取相同的观察期。
图表示例
05
—
测试用例数量
测试用例数量是CI运行里面的测试用例数，此计数应随着功能增加而相应增加。没有必要预先计划测试用例数量，因为计数本身并不重要，配套持续的增加才是关键。
例子
Java 项目运行 CI，它有 120 个 JUnit 测试用例，因此 120 是测试用例数量。过了1个月，其中的JUnit测试用例数量增加到150个。
不同CI里面的测试用例计数
由于即时 CI 具有时间限制，不能包含太多的测试用例，因此对于测试用例计数的总况掌握，它应该涵盖所有 CI。也就是说，测试用例计数是所有 CI 测试用例的总和。
对于不同的观测周期
与其他指标一起采取相同的观察期。
图表示例
小结
从DevOps整体建设而言，DevOps整体上的指标更加重要，但是对于IT开发团队而言，DevOps整体指标的获得需要更多的工作和设置，尤其是投产部分往往不在开发团队直接管辖范围之内。而其中CI部分完全在开发团队掌握之下，度量代价不贵，因此可以优先开始度量。
----全文完，以下欣奔敏捷星球介绍----
笔者自2018年12月开启欣奔敏捷星球，在这里记录敏捷教练一线实战情况，记录最真实的具体实例，积累达600多条内容，覆盖了IT敏捷+业务敏捷+DevOps的诸多细节。
本星球展示了更快交付的敏捷方法：在百人级规模，采用需求流模式，让创意从选择启动到上线只需要一个月时间，快速响应市场变化，更快捕捉市场机会。欢迎朋友们来看看:)
欣奔敏捷星球记录了从IT到业务的敏捷实践以及DevOps建设实战情况，提供最鲜活的真实案例。也有成员基于实践情况的提问和解答，星主提供远程教练咨询服务。
目前积累内容包括全套敏捷项目管理教材，ScrumBan欣奔版，需求流模式，DevOps具体解决方案。
