项目的价值流分析
价值流分析提供有关软件开发过程每个阶段的指标。
价值流是为客户提供价值的整个工作流程。例如,DevOps 生命周期是一个价值流,从管理阶段开始,到防护阶段结束。
使用价值流分析来识别:
- 从构思到生产所需的时间。
- 特定项目的速度。
- 开发过程中的瓶颈。
- 导致您的软件开发生命周期减慢的因素。
价值流分析也可用于群组。
查看价值流分析
- 过滤功能引入于 14.3 版本
- 排序功能引入于 14.4 版本
要查看项目的价值流分析:
- 在顶部栏上,选择 主菜单 > 项目 并找到您的项目。
- 在左侧边栏上,选择 分析 > 价值流。
- 要查看每个阶段的指标,在 过滤结果 文本框上方,选择一个阶段。
- 可选。过滤结果:
- 选择 过滤结果 文本框。
- 选择一个参数。
- 选择一个值或输入文本来优化结果。
- 要调整日期范围:
- 在 从 字段中,选择开始日期。
- 在 到 字段中,选择结束日期。
- 可选。按升序或降序对结果进行排序:
- 要按最新或最旧的工作流事项排序,请选择 最近活动 header。
- 要按每个阶段花费的时间最多或最少进行排序,请选择 时长 header。
该表显示所选阶段的相关工作流事项列表。根据您选择的阶段,可以是:
- CI/CD 作业
- 议题
- 合并请求
- 流水线
工作流程事项表 header 旁边的标识,显示完成所选阶段的工作流程事项的数量。
查看每个开发阶段花费的时间
价值流分析显示了每个开发阶段中议题或合并请求所花费的平均时间。
要查看每个阶段花费的中位时间:
- 在顶部栏上,选择 主菜单 > 项目 并找到您的项目。
- 在左侧边栏上,选择 分析 > 价值流。
- 可选。过滤结果:
- 选择 过滤结果 文本框。
- 选择一个参数。
- 选择一个值或输入文本来优化结果。
- 调整日期范围:
- 在 从 字段中,选择开始日期。
- 在 到 字段中,选择结束日期。
- 要查看每个阶段的中位时间,请在 过滤结果 文本框上方,指向一个阶段。
查看议题的前置时间和周期时间
价值流分析显示项目中议题的前置时间和周期时间:
- 前置时间:从创建议题到关闭议题的时间中位值。
- 周期时间:从第一次提交到议题关闭的时间的中位值。系统测量从关联议题的合并请求的最早提交,到该议题关闭的周期时间。周期时间方法低估了前置时间,因为合并请求的创建总是晚于提交时间。
要查看议题的前置时间和周期时间:
- 在顶部栏上,选择 主菜单 > 项目 并找到您的项目。
- 在左侧边栏上,选择 分析 > 价值流。
- 可选。过滤结果:
- 选择 过滤结果 文本框。
- 选择一个参数。
- 选择一个值或输入文本以优化结果。
- 调整日期范围:
- 在 从 字段中,选择开始日期。
- 在 到 字段中,选择结束日期。
前置时间 和 周期时间 指标显示在 过滤结果 文本框下方。
查看合并请求变更的前置时间
引入于 14.5 版本
变更的前置时间是合并请求从合并到部署到生产之间的持续时间的中位值。
要查看项目中合并请求变更的前置时间:
- 在顶部栏上,选择 主菜单 > 项目 并找到您的项目。
- 在左侧边栏上,选择 分析 > 价值流。
- 可选。过滤结果:
- 选择 过滤结果 文本框。
- 选择一个参数。
- 选择一个值或输入文本来优化结果。
- 调整日期范围:
- 在 从 字段中,选择开始日期。
- 在 到 字段中,选择结束日期。
过滤结果 文本框下方显示 变更的前置时间 指标。
查看成功部署的数量
先决条件:
- 要查看部署指标,您必须配置生产环境。
价值流分析显示您项目的以下部署指标:
- 部署:日期范围内成功部署的次数。
- 部署频率:日期范围内每天成功部署的平均次数。
如果您有专业版或旗舰版订阅:
- 成功部署的数量是使用 DORA 数据计算的。
- 根据环境和环境的级别过滤数据。
查看项目的部署指标:
- 在顶部栏上,选择 主菜单 > 项目 并找到您的项目。
- 在左侧边栏上,选择 分析 > 价值流。
- 可选。过滤结果:
- 选择 过滤结果 文本框。
- 选择一个参数。
- 选择一个值或输入文本来优化结果。
- 调整日期范围:
- 在 从 字段中,选择开始日期。
- 在 到 字段中,选择结束日期。
部署 和 部署频率 指标显示在 过滤结果 文本框下方。
部署指标是根据 DORA API 中的数据计算的。
在 13.9 及更高版本中,指标是根据部署完成的时间计算的。在 13.8 及更早版本中,指标是根据创建部署的时间计算的。
价值流分析的访问权限
价值流分析的访问权限取决于项目类型。
项目类型 | 权限 |
---|---|
公开 | 任何人可以访问。 |
内部 | 任何经过身份验证的用户可以访问。 |
私有 | 任何访客级别及以上的成员可以访问。 |
价值流分析如何测量每个阶段
价值流分析使用开始和结束事件来测量议题或合并请求在每个阶段花费的时间。
例如,一个阶段可能会在用户向议题添加标记时开始,并在他们添加另一个标记时结束。 如果事项尚未到达结束事件,则该事项不包含在阶段时间计算中。
阶段 | 测量方法 |
---|---|
Issue | 创建议题和采取行动解决议题之间的时间中位值,方法是标记议题或将其添加到里程碑。仅当标记已经包含为标记创建的议题看板列表时,才会跟踪标记。 |
Plan | 您为上一阶段执行的操作与将第一次提交推送到分支之间的时间中位数。第一个分支提交会触发从 Plan 到 Code 的转换,并且该分支中至少有一个提交必须包含相关的议题编号(例如 #42 )。如果提交中不包含议题编号,则该数据不包含在阶段的测量时间中。
|
Code | 推送第一次提交(上一阶段)和创建合并请求之间的时间中位数。使用合并请求描述中的议题关闭 pattern 跟踪该过程。例如,如果使用 Close #xxx pattern 关闭议题,则 xxx 是合并请求的议题编号。如果没有关闭 pattern,则将开始时间设置为第一次提交的创建时间。
|
Test | 所有流水线从开始到结束的时间。测量为该项目运行整个流水线的时间中位数。与 GitLab CI/CD 为推送到该合并请求的提交运行每个作业所需的时间相关,如前一阶段所定义。 |
Review | 从创建到合并,评审具有关闭议题 pattern 的合并请求所需的时间中位值. |
Staging | 将合并请求(具有关闭议题 pattern)合并到第一次部署到生产环境之间的时间中位值。没有生产环境就不会收集数据。 |
示例工作流
此示例显示了一天内通过所有七个阶段的工作流。在此示例中,已创建里程碑并配置了用于测试和设置环境的 CI。
- 09:00:创建议题。Issue 阶段开始。
- 11:00:将议题添加到里程碑,开始处理议题,并在本地创建分支。Issue 阶段结束,Plan 阶段开始。
- 12:00:进行第一次提交。
- 12:30:对提及议题编号的分支进行第二次提交。Plan 阶段结束,Code 阶段开始。
- 14:00:推送分支并创建包含议题关闭 pattern 的合并请求。Code 阶段结束,Test 和 Review 阶段开始。
- CI 需要 5 分钟来运行
.gitlab-ci.yml
中定义的脚本。Test 阶段结束。 - 审核合并请求。
- 19:00:合并合并请求。Review 阶段结束,Staging 阶段开始。
- 19:30:部署到“生产”环境开始并完成。Staging 阶段结束。
价值流分析记录每个阶段的以下时间:
- Issue: 09:00 to 11:00: 2 hrs
- Plan: 11:00 to 12:00: 1 hr
- Code: 12:00 to 14:00: 2 hrs
- Test: 5 minutes
- Review: 14:00 to 19:00: 5 hrs
- Staging: 19:00 to 19:30: 30 minutes
此示例还有一些其它注意事项:
- 尽管此示例在稍后的提交中指定了议题编号,但该过程仍会收集议题的分析数据。
- Test 阶段所需的时间包含在 Review 流程中,因为每个合并请求都应进行测试。
- 此示例仅说明了多个阶段的一个循环。价值流分析仪表盘显示计算出的这些议题的平均运行时间。
- 价值流分析根据环境的部署级别识别生产环境。