跳到内容

周期分析

介绍了在GitLab 8.12中。在GitLab 8.14中添加了更多的特性。

周期分析测量从一个从创意到生产对于你的每个项目。这不仅通过指出到达这一点所需的总时间来实现，而且还通过将总时间分解为想法必须经过的多个阶段来实现。

周期分析与GitLab流并为每个阶段计算一个单独的中位数。

概述

你可以在你的项目下找到Cycle Analytics页面管道➔循环分析选项卡。

Cycle Analytics登陆页面

你可以看到总共有七个阶段:

  • 问题(跟踪)
    • 从问题创建到给出里程碑或列表标签的中位数时间(第一次分配、任何里程碑、里程碑日期或受让人不需要)
  • 计划(董事会)
    • 从给一个问题一个里程碑或标签到将第一个提交推到分支的中间时间
  • 代码(IDE)
    • 从第一次提交到分支到创建合并请求的中间时间
  • 测试(CI)
    • 所有提交/合并的总测试时间的中位数
  • 审查(合并请求/先生)
    • 从创建合并请求到合并请求的中位数时间(不考虑已关闭的合并请求)
  • 暂存(持续部署)
    • 从合并请求合并到部署到生产(生产是最后一个阶段/环境)的中间时间
  • 生产(总)
    • 除测试(CI)时间外，所有以上阶段时间的总和。澄清一下，并不是说CI时间被“排除”了，而是因为CI是自动完成的，所以在评审阶段就已经计算了CI时间。大多数其他阶段都是连续的，但是测试不是。

数据是如何测量的

周期分析根据项目问题记录周期时间和数据，但登台阶段和生产阶段除外，其中只测量部署到生产阶段的数据。

具体来说，如果您的CI没有设置，并且您还没有定义生产或生产/ *环境，那么你将没有这些阶段的任何数据。

下面你可以更详细地看到周期分析的各个阶段的含义。

阶段 描述
问题 衡量从产生一个问题到采取行动解决它之间的中间时间，通过标记它或将它添加到里程碑，无论哪个先发生。标签将被跟踪，只有当它已经有发行委员会名单为它而生。
计划 度量在前一个阶段执行的操作与将第一个提交推到分支之间的中间时间。分支的第一次提交将触发之间的分离计划而且代码，分支中至少有一个提交需要包含相关的问题号(例如，# 42)．如果分支中的所有提交都没有提到相关的问题号，则不考虑该阶段的测量时间。
代码 度量推送第一次提交(前一个阶段)和创建与该提交相关的合并请求(MR)之间的中间时间。保持跟踪流程的关键是包含发行结束模式合并请求的描述(例如，关闭# xxx,在那里xxx与此合并请求相关的问题的编号)。如果问题结束模式没有出现在合并请求描述中，则不将MR考虑到该阶段的度量时间。
测试 度量该项目运行整个管道所需的中值时间。这与GitLab CI运行提交到前一阶段定义的合并请求的每个作业所需的时间有关。它基本上是所有管道的开始->结束时间。主不排除。它不试图跟踪任何特定阶段的时间。
审查 度量从创建合并请求到合并合并请求所花费的中间时间。
暂存 度量合并合并请求到第一次部署到生产之间的中间时间。它由环境设置为生产或匹配生产/ *(区分大小写,生产不会工作)在你的GitLab CI配置。如果没有生产环境，则不会跟踪。
生产 运行整个过程所花费的所有时间(中位数)的总和，从问题创建到部署代码到生产。

下面是它背后的工作原理:

  1. 问题和合并请求被成对地分组在一起，这样对于每个问题和合并请求对时，合并请求具有发行结束模式对应的问题。所有其他问题和合并请求不考虑。
  2. 然后按最近XX天(由UI - default指定为90天)过滤掉这些对。所以它禁止考虑这些对。
  3. 对于剩下的结对时，我们检查各个阶段所需的信息，如问题创建日期、合并请求合并时间等。

总之，任何不符合GitLab流根本不会被追踪。因此，Cycle Analytics仪表板不会显示任何数据:

  • 用于未关闭问题的合并请求。
  • 对于未在问题委员会中标注标签的问题。
  • 对于没有指定里程碑的问题。
  • 对于分期和制作阶段，如果项目没有生产或生产/ *环境。

示例工作流

下面是一个简单的虚构的工作流程，一个周期发生在一天内通过所有七个阶段。请注意，如果一个阶段没有开始/停止标记，则它不会被测量，因此不会在中位数时间内计算。这里假设已经创建了里程碑，并且配置了用于测试和设置环境的CI。

  1. 问题创建于09:00(开始于问题阶段)。
  2. 问题在11:00添加到一个里程碑(停止)问题阶段/开始计划阶段)。
  3. 开始处理这个问题，在本地创建一个分支，并在12:00提交一次。
  4. 第二次提交到提到问题号在12.30的分支计划阶段/开始代码阶段)。
  5. 分支并创建包含发行结束模式在它的描述在14:00(停止代码阶段/开始测试而且审查阶段)。
  6. CI开始运行中定义的脚本.gitlab-ci.yml花费5分钟(停止测试阶段)。
  7. 检查合并请求，确保一切正常，并在19:00合并合并请求。(停止的审查阶段/开始暂存阶段)。
  8. 合并请求完成后，将部署到生产环境开始和结束于19:30(停止暂存阶段)。
  9. 循环完成，前几个阶段的中值时间之和被记录到生产阶段。这是创建问题和将其相关合并请求部署到生产之间的时间。

从上面的例子中，你可以得出每个阶段完成所需的时间与它们的总时间一样长:

  • 问题: 2h (11:00 - 09:00)
  • 计划: 1h (12:00 - 11:00)
  • 代码: 2h (14:00 - 12:00)
  • 测试: 5分钟
  • 审查: 5h (19:00 - 14:00)
  • 暂存:30分钟(19:30 - 19:00)
  • 生产:由于此阶段测量的是之前所有阶段的中值时间之和，如果不知道之前阶段的状态，则无法计算。如果这是在项目中运行的第一个周期，则生产时间:10h 30min (19:30 - 09:00)

注意事项:

  • 在上面的例子中，我们演示了如果你的第一次提交没有提到问题号并不重要，你可以在你正在处理的分支的任何提交中这样做。
  • 你可以看到测试阶段不计算周期的总时间，因为它包含在审查过程(每个MR都应该测试)。
  • 上面的例子只是一个周期在七个阶段中。添加多个周期，计算它们的中值时间，结果就是周期分析的仪表板所显示的结果。

权限

Cycle Analytics仪表板上的当前权限是:

  • 公共项目-任何人都可以访问
  • 私人/内部项目-任何成员(客户级别及以上)都可以访问

你可以阅读更多关于权限的信息一般来说。

更多的资源

在以下资源中了解更多关于周期分析的知识:

Baidu
map