DevOps 研究和评估 (DORA) 关键指标
- 引入于 13.7 版本
- 于 13.10 版本添加对于变更的前置时间的支持。
- 极狐GitLab 自 15.4 版本开始,将该功能从旗舰版降入专业版。而 GitLab CE 与 EE 版本中,该功能依旧为旗舰版。
- 极狐GitLab 自 15.8 版本开始,将该功能从专业版调整为旗舰版。
DevOps 研究和评估 (DORA) 团队确定了衡量 DevOps 性能的四个指标。 使用这些指标有助于提高 DevOps 效率并向业务利益相关者传达性能,从而加速业务成果。
DORA 包括四个关键指标,分为 DevOps 的两个核心领域:
对于软件开发领导者而言,跟踪速度和质量指标可确保他们不会为了速度而牺牲质量。
部署频率
成功部署到生产环境的相对频率(每小时、每天、每周、每月或每年),衡量了您向最终用户交付价值的频率。更高的部署频率意味着您能够获得反馈并更快地迭代来提供改进和功能。极狐GitLab 测量在特定时间段内部署到生产环境的数量。
部署频率显示在以下几个图表中:
变更的前置时间
DORA 变更的前置时间衡量的是成功将功能交付到生产中的时间。 该指标反映了 CI/CD 流水线的效率。
在极狐GitLab 中,变更的前置时间计算合并请求合并到生产环境中所需的中位时间。 我们测量“从代码提交到代码在生产中成功运行”,而不将 “coding 时间”添加到计算中。
随着时间的推移,变更的前置时间应该会减少,而您的团队的绩效应该会提高。
变更的前置时间显示在以下几个图表中:
恢复服务时间
组织从生产环境失败中恢复需要多长时间。极狐GitLab 测量在特定时间段内,关闭事件(incidents)所需的平均时间。假设:
- 所有事件都与生产环境相关。
- 事件和部署具有严格的一对一关系(意味着任何事件仅与一个生产部署相关,任何生产部署与不超过一个事件相关)。
恢复服务的时间显示在几个图表中:
要获取恢复服务时间指标,使用 GraphQL 或 REST APIs。
变更失败率
导致生产环境失败的部署百分比。极狐GitLab 测量在特定时间段内,事件(incidents)数量除以生产环境的部署数量的值。假设:
- 所有事件都与生产环境有关。
- 事件和部署具有严格的一对一关系(意味着任何事件仅与一个生产部署相关,任何生产部署与不超过一个事件相关)。
要获取变更失败率,使用 GraphQL 或 REST APIs。
洞见:自定义 DORA 报告
使用基于 YAML 的 Insights 报告可视化 DORA 数据的自定义图表。
通过这种新的可视化,软件开发领导者可以跟踪指标改进,了解指标趋势,并比较团队和项目之间的绩效。
在不使用极狐GitLab CI/CD 流水线的情况下测量 DORA 指标
部署频率是根据部署记录计算的,该记录是为典型的基于推送的部署创建的。 这些部署记录不是为基于拉取的部署创建的,例如当容器镜像通过代理连接到极狐GitLab 时。
要在这些情况下跟踪 DORA 指标,您可以使用部署 API 创建部署记录。
极狐GitLab 中支持的指标
下表显示了受支持的指标、它们在哪个级别上受支持以及引入于哪个版本(API 和 UI):
指标 | 级别 | API 版本 | 图表(UI)版本 | 备注 |
---|---|---|---|---|
deployment_frequency
| 项目级别 | 13.7+ | 14.8+ | |
deployment_frequency
| 群组级别 | 13.10+ | 13.12+ | |
lead_time_for_changes
| 项目级别 | 13.10+ | 13.11+ | 以秒为单位。聚合方法为中位数。 |
lead_time_for_changes
| 群组级别 | 13.10+ | 14.0+ | 以秒为单位。聚合方法为中位数。 |
change_failure_rate
| 项目/群组级别 | 14.9+ | 15.1+ | 以天为单位。聚合方法是中位数。 |
time_to_restore_service
| 项目/群组级别 | 14.10+ | 15.2+ | 部署百分比。 |