Help us learn about your current experience with the documentation. Take the survey.

价值流分析

  • 层级:Free, Premium, Ultimate
  • 版本:GitLab.com, GitLab Self-Managed, GitLab Dedicated

价值流分析会计算您软件开发流程中每个阶段的耗时。 通过跟踪合并请求(merge request)或问题(issue)事件,您可以衡量从创意到生产所需的时间。

使用价值流分析可识别:

  • 从创意到生产所需的时间
  • 特定项目的交付速度
  • 开发流程中的瓶颈
  • 长期未解决的问题或合并请求
  • 导致软件开发生命周期放缓的因素

价值流分析帮助企业:

  • 可视化端到端的 DevSecOps 工作流
  • 识别并解决效率问题
  • 优化工作流以更快交付更多价值(例如,减少合并请求审查时间

点击查看演示:价值流管理产品导览

价值流分析采用分层结构:

  • 价值流包含价值流阶段列表
  • 每个价值流阶段列表包含一个或多个阶段
  • 每个阶段由两个事件定义:开始和结束

价值流

价值流是为客户交付价值的完整工作流程。 价值流是阶段的容器对象。 每个组可以有多个价值流,以关注 DevOps 生命周期的不同方面。

价值流阶段

阶段表示带有附加元数据的事件对(开始和结束事件),例如阶段名称。 您可以使用内置的默认阶段进行价值流分析,这些阶段可重新排序和隐藏。 您也可以创建并添加符合特定开发工作流的自定义阶段。

价值流阶段事件

事件定义阶段开始和结束的基本构建块。 每个事件都有开始和结束时间:

  • 开始事件时间:标记阶段工作开始的时间(例如,问题创建时)
  • 结束事件时间:标记阶段工作完成的时间(例如,问题关闭时)

GitLab 基于开始和结束事件时间计算阶段耗时,使用公式: 阶段耗时 = 结束事件时间 - 开始事件时间

价值流分析支持以下事件:

  • 问题关闭
  • 问题创建
  • 首次添加到看板
  • 首次添加到迭代
  • 首次分配
  • 首次关联里程碑
  • 首次在提交中提及
  • 问题标签添加
  • 问题标签移除
  • 合并请求关闭
  • 合并请求创建
  • 合并请求首次分配
  • 合并请求首次提交
  • 合并请求首次部署到生产环境
  • 合并请求标签添加
  • 合并请求标签移除
  • 合并请求最终批准
  • 合并请求最终构建完成
  • 合并请求最终构建开始
  • 合并请求已合并
  • 合并请求审查者首次分配

您可以在 issue 520962 中分享关于阶段事件的想法或反馈。

数据聚合

  • 层级:Premium, Ultimate
  • 版本:GitLab.com, GitLab Self-Managed, GitLab Dedicated

价值流分析使用后端流程收集和聚合阶段级数据,确保其可扩展到包含大量问题和合并请求的大型组。由于此流程,执行操作(例如关闭问题)与数据在价值流分析页面显示之间可能存在轻微延迟。

数据处理和显示结果可能需要最多 10 分钟。在以下情况下,数据收集可能超过 10 分钟:

  • 如果是首次查看价值流分析且尚未创建价值流
  • 如果组层次结构已重新排列
  • 如果问题和合并请求有批量更新

要查看数据最近更新时间,在 Edit 右上角悬停 Last updated 徽标。

阶段测量

价值流分析测量每个阶段从开始事件到结束事件的耗时。 只有已到达结束事件的条目才会包含在阶段时间计算中。

默认情况下,被阻塞的问题不包含在生命周期概览中。 但您可以使用自定义标签(例如 workflow::blocked)来跟踪它们。

您可以根据预定义事件自定义价值流分析中的阶段。 为帮助您配置,GitLab 提供了预定义阶段列表作为模板。 例如,您可以定义一个阶段,当为问题添加标签时开始,添加另一个标签时结束。

下表概述了价值流分析中的预定义阶段。

阶段 测量方法
问题 从创建问题到采取解决措施(标记或添加里程碑,以先发生者为准)的中位时间。仅当问题已有看板列表时才跟踪标签。
计划 从上一阶段操作到首次提交到分支的中位时间。分支上的首次提交触发 PlanCode 的分离。分支中至少有一个提交必须包含相关问题编号(例如 #42)。如果分支中没有提交提及问题编号,则不计入阶段测量时间。
代码 从首次提交(上一阶段)到创建相关合并请求的中位时间。保持流程跟踪的关键是在合并请求描述中包含问题关闭模式。例如 Closes #xxx,其中 xxx 是此合并请求相关的问题编号。如果缺少关闭模式,则使用合并请求中首次提交的创建时间作为开始时间。
测试 运行整个项目管道的中位时间。与 GitLab CI/CD 为提交到该合并请求的作业运行所需时间相关。基本上是所有管道的开始→结束时间。
审查 对包含关闭问题模式的合并请求,从创建到合并的中位审查时间。
部署 从合并包含关闭问题模式的合并请求到首次部署到生产环境的中位时间。如果没有生产环境,则不跟踪。

价值流分析基于时间戳数据,仅聚合阶段最终的开始和结束事件。对于在阶段间多次移动的条目,阶段时间仅根据最终事件的时间戳计算。

示例工作流

此示例展示一天内通过所有七个阶段的工作流。

如果阶段不包含开始和结束时间,其数据不包含在中位时间中。 在此示例中,已创建里程碑,且测试和设置环境的 CI/CD 已配置。

  • 09:00:创建问题。问题阶段开始。
  • 11:00:将问题添加到里程碑(或待办事项),开始处理问题并在本地创建分支。 问题阶段结束,计划阶段开始。
  • 12:00:进行首次提交。
  • 12:30:在提及问题编号的分支上进行第二次提交。 计划阶段结束,代码阶段开始。
  • 14:00:推送分支并创建包含问题关闭模式的合并请求。 代码阶段结束,测试审查阶段开始。
  • GitLab CI/CD 用 5 分钟运行 .gitlab-ci.yml 文件 中定义的脚本。
  • 19:00:合并合并请求。审查阶段结束,部署阶段开始。
  • 19:30:部署到 production 环境完成。部署阶段结束。

价值流分析记录各阶段的以下时间:

  • 问题:09:00 至 11:00:2 小时
  • 计划:11:00 至 12:00:1 小时
  • 代码:12:00 至 14:00:2 小时
  • 测试:5 分钟
  • 审查:14:00 至 19:00:5 小时
  • 部署:19:00 至 19:30:30 分钟

注意此示例相关的以下观察:

  • 此示例表明,即使首次提交未提及问题编号,您也可以在分支上的任何后续提交中添加。
  • 测试阶段用于计算整体周期时间。它包含在审查过程中,因为每个合并请求都应经过测试。
  • 此示例仅展示七个阶段的一个周期。价值流分析仪表板显示多个周期的中位时间。

累积标签事件耗时

此功能使价值流分析能够测量基于标签阶段的重复事件耗时。您应为开始和结束事件配置标签移除或添加事件。

例如,一个阶段跟踪 in progress 标签的添加和移除,时间如下:

  • 9:00:添加标签。
  • 10:00:移除标签。
  • 12:00:添加标签。
  • 14:00:移除标签。

使用原始计算方法,耗时为 5 小时(从 9:00 到 14:00)。 启用累积标签事件耗时计算后,耗时为 3 小时(9:00 至 10:00 和 12:00 至 14:00)。

当您将 GitLab 版本升级到 16.10 或更高版本时,现有的基于标签的价值流分析阶段将使用后台聚合过程自动重新聚合。

升级后重新聚合数据

  • 版本:GitLab Self-Managed

在大型实例上,当您升级 GitLab 版本时,特别是跳过多个次版本时,后台聚合过程可能耗时更长。此延迟可能导致价值流分析页面上的数据过时。 为加快聚合速度并避免数据过时,在 rails console 中,您可以为给定组调用同步聚合代码片段:

group = Group.find(-1) # 在此处输入您的组 ID
group_to_aggregate = group.root_ancestor

loop do
  cursor = {}
  context = Analytics::CycleAnalytics::AggregationContext.new(cursor: cursor)
  service_response = Analytics::CycleAnalytics::DataLoaderService.new(group: group_to_aggregate, model: Issue, context: context).execute

  if service_response.success? && service_response.payload[:reason] == :limit_reached
    cursor = service_response.payload[:context].cursor
  elsif service_response.success?
    puts "finished"
    break
  else
    puts "failed"
    break
  end
end

loop do
  cursor = {}
  context = Analytics::CycleAnalytics::AggregationContext.new(cursor: cursor)
  service_response = Analytics::CycleAnalytics::DataLoaderService.new(group: group_to_aggregate, model: MergeRequest, context: context).execute

  if service_response.success? && service_response.payload[:reason] == :limit_reached
    cursor = service_response.payload[:context].cursor
  elsif service_response.success?
    puts "finished"
    break
  else
    puts "failed"
    break
  end
end

生产环境

价值流分析通过查找项目环境名称匹配以下模式来识别生产环境

  • prodprod/*
  • productionproduction/*

这些模式不区分大小写。

您可以在 GitLab CI/CD 配置中更改项目环境的名称。

查看价值流分析

前提条件:

  • 您必须至少拥有 Reporter 角色。
  • 您必须创建自定义价值流。价值流分析仅显示为您的组或项目创建的自定义价值流。

要查看组或项目的价值流分析:

  1. 在左侧边栏,选择 Search or go to 并找到您的项目或组。
  2. 选择 Analyze > Value stream analytics
  3. 要查看特定阶段的指标,在 Filter results 文本框下方选择一个阶段。
  4. 可选:过滤结果:
    1. 选择 Filter results 文本框。

    2. 选择一个参数。

    3. 选择一个值或输入文本以细化结果。

    4. 要查看特定日期范围的指标,从下拉列表中选择预定义日期范围或 Custom 选项。选择 Custom 选项后:

      • From 字段中选择开始日期。
      • To 字段中选择结束日期。

      图表和列表将显示日期范围内创建的工作流项。

  5. 可选:按升序或降序排序结果:
    • 要按最新或最旧的工作流项排序,选择 Last event 标题。
    • 要按每个阶段花费最多或最少时间排序,选择 Duration 标题。

工作流项表格标题旁边的徽标显示所选阶段内完成的工作流项数量。

该表显示所选阶段的关联工作流项列表。根据您选择的阶段,这可能是:

  • 问题(Issues)
  • 合并请求(Merge requests)

每个预定义日期范围的结束日期是当前日期,并包含在所选的天数中。例如,Last 30 days 的开始日期是当前日期前 29 天,总计 30 天。

数据过滤器

您可以过滤价值流分析以查看符合特定条件的数据。支持以下过滤器:

  • 日期范围
  • 项目
  • 分配人
  • 作者
  • 里程碑
  • 标签

价值流分析指标

价值流分析的 Overview 页面显示项目和组的 DevSecOps 生命周期性能关键指标。

生命周期指标

价值流分析包含以下生命周期指标:

  • 前置时间(Lead time):从问题创建到关闭的中位时间。
  • 周期时间(Cycle time):从问题首次在合并请求的提交消息中被引用到该引用问题关闭的中位时间。您必须在提交消息中包含 # 加上问题编号(例如 #123),否则不显示数据。周期时间通常短于前置时间,因为合并请求在首次提交后创建。
  • 新问题数量:创建的新问题数量。
  • 部署次数:部署到生产的总次数。

DORA 指标

  • 层级:Ultimate
  • 版本:GitLab.com, GitLab Self-Managed, GitLab Dedicated

价值流分析包含以下 DORA 指标:

  • 部署频率(Deployment frequency)
  • 变更前置时间(Lead time for changes)
  • 服务恢复时间(Time to restore service)
  • 变更失败率(Change failure rate)

DORA 指标基于 DORA API 的数据计算。

如果您拥有 GitLab Premium 或 Ultimate 订阅:

  • 成功部署次数使用 DORA 数据计算。
  • 数据根据环境和环境层级进行过滤。

查看生命周期和 DORA 指标

前提条件:

要查看生命周期指标:

  1. 在左侧边栏,选择 Search or go to 并找到您的项目或组。
  2. 选择 Analyze > Value stream analytics。 生命周期指标显示在 Filter results 文本框下方。
  3. 可选:过滤结果:
    1. 选择 Filter results 文本框。 根据您选择的过滤器,仪表板会自动聚合生命周期指标并显示价值流状态。
    2. 选择一个参数。
    3. 选择一个值或输入文本以细化结果。
    4. 要调整日期范围:
      • From 字段中选择开始日期。
      • To 字段中选择结束日期。

要查看 价值流仪表板DORA 指标

  1. 在左侧边栏,选择 Search or go to 并找到您的项目或组。
  2. 选择 Analyze > Value stream analytics
  3. Filter results 文本框下方,在 Lifecycle metrics 行中选择 Value Streams Dashboard / DORA
  4. 可选:要打开新页面,将路径 /analytics/dashboards/value_streams_dashboard 附加到组 URL (例如 https://gitlab.com/groups/gitlab-org/-/analytics/dashboards/value_streams_dashboard)。

查看各开发阶段的指标

价值流分析显示问题或合并请求在每个开发阶段花费的中位时间。

要查看组内各阶段的中位时间:

  1. 在左侧边栏,选择 Search or go to 并找到您的项目或组。
  2. 选择 Analyze > Value stream analytics
  3. 可选:过滤结果:
    1. 选择 Filter results 文本框。
    2. 选择一个参数。
    3. 选择一个值或输入文本以细化结果。
    4. 要调整日期范围:
      • From 字段中选择开始日期。
      • To 字段中选择结束日期。
  4. 要查看各阶段的指标,在 Filter results 文本框上方悬停一个阶段。

日期范围选择器按事件时间过滤条目。事件时间是所选阶段为给定条目完成的时间。

按类型查看任务

  • 层级:Premium, Ultimate
  • 版本:GitLab.com, GitLab Self-Managed, GitLab Dedicated

按类型任务图表显示组内每日已完成任务(关闭的问题和已合并的合并请求)的累计数量。

该图表使用全局页面过滤器根据所选组和时间段显示数据。

要按类型查看任务:

  1. 在左侧边栏,选择 Search or go to 并找到您的组。
  2. 选择 Analyze > Value stream analytics
  3. Filter results 文本框下方,选择 Overview按类型任务图表显示在 总时间 图表下方。
  4. 可选:要按类型过滤任务,选择 Settings ( settings ),然后选择 IssuesMerge Requests
  5. 可选:要按标签过滤任务,选择 Settings ( settings ),然后选择一个或多个标签。默认选择顶级组标签(最多 10 个)。最多可选择 15 个标签。

创建价值流

  • 层级:Premium, Ultimate
  • 版本:GitLab.com, GitLab Self-Managed, GitLab Dedicated

使用默认阶段

要创建带有默认阶段的价值流:

  1. 在左侧边栏,选择 Search or go to 并找到您的项目或组。
  2. 选择 Analyze > Value Stream analytics
  3. 选择 New Value Stream
  4. 输入价值流名称。
  5. 选择 Create from default template
  6. 自定义默认阶段:
    • 要重新排序阶段,选择上箭头或下箭头。
    • 要隐藏阶段,选择 Hide ( eye-slash )。
  7. 要添加自定义阶段,选择 Add a stage
    • 输入阶段名称。
    • 选择 Start eventStop event
  8. 选择 New value stream

如果您最近升级到 GitLab Premium,数据收集和显示可能需要最多 30 分钟。

使用自定义阶段

要创建带有自定义阶段的价值流:

  1. 在左侧边栏,选择 Search or go to 并找到您的项目或组。
  2. 选择 Analyze > Value Stream analytics
  3. 选择 New value stream
  4. 对于每个阶段:
    • 输入阶段名称。
    • 选择 Start eventStop event
  5. 要添加另一个阶段,选择 Add a stage
  6. 要重新排序阶段,选择上箭头或下箭头。
  7. 选择 New value stream

视频说明请参见 使用价值流分析优化合并请求审查流程

自定义价值流的基于标签的阶段

为测量复杂工作流,您可以使用作用域标签。例如,要测量从暂存环境到生产环境的部署时间,可以使用以下标签:

  • 当代码部署到暂存环境时,向合并请求添加 workflow::staging 标签。
  • 当代码部署到生产环境时,向合并请求添加 workflow::production 标签。

基于标签的价值流分析阶段

使用 Webhook 自动标记数据

您可以使用 GitLab webhook 事件 自动添加标签,以便在发生特定事件时将标签应用于合并请求或问题。 然后,您可以添加基于标签的阶段来跟踪您的工作流。 有关实现的更多信息,请参阅博客文章 自动应用 GitLab 标签

示例配置

示例配置

在上例中,为 Test Group(顶级命名空间)中采用不同开发工作流的两个团队设置了两个独立的价值流。

第一个价值流使用基于标准时间戳的事件定义阶段。第二个价值流使用标签事件。

编辑价值流

  • 层级:Premium, Ultimate
  • 版本:GitLab.com, GitLab Self-Managed, GitLab Dedicated

创建价值流后,您可以自定义以适应您的需求。要编辑价值流:

  1. 在左侧边栏,选择 Search or go to 并找到您的项目或组。
  2. 选择 Analyze > Value stream analytics
  3. 从价值流下拉列表中选择要编辑的价值流。
  4. 在价值流下拉列表旁边,选择 Edit
  5. 可选:
    • 重命名价值流。
    • 隐藏或重新排序默认阶段。
    • 删除现有自定义阶段。
    • 要添加新阶段,选择 Add a stage
    • 选择阶段的开始和结束事件。
  6. 可选:要撤销任何修改,选择 Restore value stream defaults
  7. 选择 Save Value Stream

删除价值流

  • 层级:Premium, Ultimate
  • 版本:GitLab.com, GitLab Self-Managed, GitLab Dedicated

要删除自定义价值流:

  1. 在左侧边栏,选择 Search or go to 并找到您的项目或组。
  2. 选择 Analyze > Value stream analytics
  3. 从价值流下拉列表中选择要删除的价值流,然后选择 Delete (name of value stream)
  4. 确认选择 Delete

查看周期完成天数

  • 层级:Premium, Ultimate
  • 版本:GitLab.com, GitLab Self-Managed, GitLab Dedicated

总时间图表 显示开发周期完成所需的平均天数。 图表显示最近 500 个工作流项的数据。

  1. 在左侧边栏,选择 Search or go to 并找到您的项目或组。
  2. 选择 Analyze > Value stream analytics
  3. Filter results 框上方,选择一个阶段:
    • 要查看所有阶段的周期时间摘要,选择 Overview
    • 要查看特定阶段的周期时间,选择一个阶段。
  4. 可选:过滤结果:
    1. 选择 Filter results 文本框。
    2. 选择一个参数。
    3. 选择一个值或输入文本以细化结果。
    4. 要调整日期范围:
      • From 字段中选择开始日期。
      • To 字段中选择结束日期。

访问权限

价值流分析的访问权限取决于项目类型。

项目类型 权限
公开 任何人都可以访问。
内部 任何经过身份验证的用户都可以访问。
私有 任何至少拥有 Guest 角色的用户都可以访问。

价值流分析 GraphQL API

  • 层级:Free, Premium, Ultimate
  • 版本:GitLab.com, GitLab Self-Managed, GitLab Dedicated

使用 VSA GraphQL API,您可以请求配置的价值流和阶段指标。如果您要将 VSA 数据导出到外部系统或用于报告,这很有用。

以下指标可用:

  • 阶段中已完成项目的数量。计数最多限制为 10,000 个项目。
  • 阶段中已完成项目的中位耗时。
  • 阶段中已完成项目的平均耗时。

请求指标

前提条件:

  • 您必须至少拥有 Reporter 角色。

首先,您必须确定要在报告中使用哪个价值流。

要请求组的配置价值流,运行:

group(fullPath: "your-group-path") {
  valueStreams {
    nodes {
      id
      name
    }
  }
}

类似地,要请求项目的指标,运行:

project(fullPath: "your-project-path") {
  valueStreams {
    nodes {
      id
      name
    }
  }
}

要请求价值流阶段的指标,运行:

group(fullPath: "your-group-path") {
  valueStreams(id: "your-value-stream-id") {
    nodes {
      stages {
        id
        name
      }
    }
  }
}

根据您如何消费数据,您可以请求一个特定阶段或价值流中所有阶段的指标。

请求所有阶段的指标对某些安装可能太慢。 推荐的方法是逐个请求阶段指标。

请求阶段指标:

group(fullPath: "your-group-path") {
  valueStreams(id: "your-value-stream-id") {
    nodes {
      stages(id: "your-stage-id") {
        id
        name
        metrics(timeframe: { start: "2024-03-01", end: "2024-03-31" }) {
          average {
            value
            unit
          }
          median {
            value
            unit
          }
          count {
            value
            unit
          }
        }
      }
    }
  }
}

您始终应请求给定时间段的指标。 支持的最长时间段为 180 天。

metrics 节点支持其他过滤选项:

  • 分配人用户名
  • 作者用户名
  • 标签名称
  • 里程碑标题

带过滤器的示例请求:

group(fullPath: "your-group-path") {
  valueStreams(id: "your-value-stream-id") {
    nodes {
      stages(id: "your-stage-id") {
        id
        name
        metrics(
          labelNames: ["backend"],
          milestoneTitle: "17.0",
          timeframe: { start: "2024-03-01", end: "2024-03-31" }
        ) {
          average {
            value
            unit
          }
          median {
            value
            unit
          }
          count {
            value
            unit
          }
        }
      }
    }
  }
}

最佳实践

  • 要获得当前状态的准确视图,尽可能在时间段结束时请求指标。
  • 对于定期报告,您可以创建脚本并使用计划流水线功能及时导出数据。
  • 调用 API 时,您从数据库获取当前数据。随着时间的推移,由于数据库中基础数据的变化,相同的指标可能会改变。例如,移动或从组中删除项目可能会影响组级指标。
  • 重新请求先前时期的指标并与先前收集的指标进行比较,可以显示数据偏差,这有助于发现和解释变化趋势。

预测部署频率

  • 层级:Ultimate
  • 版本:GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • 状态:实验性功能

通过预测整个软件开发生命周期的生产力指标和识别异常,改进您的规划和决策。

前提条件:

要在 CI/CD 分析中查看部署频率预测:

  1. 在左侧边栏,选择 Search or go to 并找到您的项目。
  2. 选择 Analyze > CI/CD analytics
  3. 选择 Deployment frequency 选项卡。
  4. 打开 Show forecast 开关。
  5. 在确认对话框中,选择 Accept testing terms

预测以虚线形式显示在图表上。数据预测的时间长度为所选日期范围的一半。

例如,如果您选择 30 天范围,将显示随后 15 天的预测。

预测部署频率

在此实验性功能上提供反馈,请访问 issue 416833

功能可用性

价值流分析在项目和组级别为 FOSS 和许可版本提供不同功能。

  • 在 GitLab Free 上,价值流分析不聚合数据。它直接查询数据库,日期范围过滤器应用于问题和合并请求的创建日期。您可以使用预定义的默认阶段查看价值流分析。
  • 在 GitLab Premium 上,价值流分析聚合数据并将日期范围过滤器应用于结束事件。您还可以创建、编辑和删除价值流。
功能 组级别(许可版本) 项目级别(许可版本) 项目级别(FOSS)
创建自定义价值流 否,仅存在一个带有默认阶段的默认价值流
创建自定义阶段
过滤(例如按作者、标签、里程碑)
阶段时间图表
总时间图表
按类型任务图表
DORA 指标
周期时间和前置时间摘要(生命周期指标)
新问题、提交和部署(生命周期指标) 是(不包括提交)
使用聚合后端
日期过滤器行为 过滤在日期范围内完成的条目 按创建日期过滤条目 按创建日期过滤条目
访问权限 至少 Reporter 角色 至少 Reporter 角色 可公开访问

故障排除

Sidekiq cronjob:analytics_cycle_analytics CPU 利用率 100%

价值流分析后台作业可能通过占用 CPU 资源严重影响性能。

要从此情况中恢复:

  1. rails console 中为所有项目禁用该功能,并删除现有作业:

    Project.find_each do |p|
      p.analytics_access_level='disabled';
      p.save!
    end
    
    Analytics::CycleAnalytics::GroupStage.delete_all
    Analytics::CycleAnalytics::Aggregation.delete_all
  2. 配置 Sidekiq 路由, 例如单个 feature_category=value_stream_management 条目和多个 feature_category!=value_stream_management 条目。 在 企业版列表 中查找其他相关队列元数据。

  3. 逐个项目启用价值流分析。 您可能需要根据性能要求进一步调整 Sidekiq 路由。