您的软件开发生命周期数据模板
您的软件开发生命周期数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 提取指南
软件开发生命周期属性
| 名称 | 描述 | ||
|---|---|---|---|
|
开发项
DevelopmentItemId
|
单个开发工作单元(如功能、bug 修复或任务)的唯一标识符。这作为主要的 case 标识符。 | ||
|
描述
开发项 ID(Development Item ID)跟踪从创建到最终部署的工作项。它将所有关联活动(如分支创建、commit、pull request、审查和部署)链接到一个单一、内聚的流程实例中。 在分析中,此 ID 用于计算开发任务的端到端周期时间。它可以重建功能开发或 bug 修复的整个历程,从而能够对单个工作项的瓶颈、返工循环和流程变体进行详细分析。
为何重要
它是 Process Mining 的核心键,将所有相关的开发事件连接到单个 Case 中,从而准确地可视化并分析端到端的软件开发生命周期。
获取方式
这通常是来自 GitHub 的 Issue 编号或 Pull Request 编号。它可以从 issue 或 pull request 相关 webhook 事件或 API 响应的载荷中的 “number” 字段中提取。
示例
101PR-2345TASK-812
|
|||
|
开始时间
EventTimestamp
|
特定开发活动或事件发生的确切日期和时间。 | ||
|
描述
此时间戳标记活动的开始。它对于按时间顺序排列事件以重建每个开发项的流程流至关重要。这些时间戳之间的顺序和时间差用于分析流程绩效。 在分析中,此属性对于计算所有基于时间的指标(包括周期时间、处理时间和等待时间)必不可少。它有助于识别步骤之间的延迟,并为瓶颈分析和绩效监控仪表板提供所需数据。
为何重要
此时间戳对于正确排列事件顺序以及计算所有绩效指标(如周期时间和瓶颈时长)至关重要。
获取方式
通常在 GitHub API 和 webhook 针对 issue、pull request 和 commit 等各种对象的 JSON 载荷中的 “created_at” 或 “updated_at” 字段中找到。
示例
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
|
|||
|
活动
ActivityName
|
在软件开发生命周期内发生的特定事件或任务的名称。 | ||
|
描述
活动名称(Activity Name)描述了开发流程中的单个步骤,例如“Issue 已创建”、“代码已推送到 PR”、“Pull Request 已批准”或“部署成功”。这些事件形成了构成开发项端到端流程的步骤序列。 此属性是流程挖掘的基础,因为它用于构建流程图。分析这些活动的顺序、频率和持续时间可以揭示实际的流程,识别常用路径,突出显示偏差,并精准定位瓶颈。
为何重要
此属性构成了流程图的主干,支持对开发生命周期中事件序列的可视化和分析。
获取方式
派生自 Webhook 事件负载的 'action' 字段(例如 Issue 的 'opened'、'closed')或事件类型本身(例如 'PushEvent'、'PullRequestReviewEvent')。
示例
问题已创建Pull Request 已打开代码已推送到 PR已请求审查Pull Request 已合并
|
|||
|
仓库
RepositoryName
|
进行开发活动的项目的代码仓库名称。 | ||
|
描述
仓库(Repository)充当项目或产品标识符,包含特定应用程序或组件的所有代码、issue 和 pull request。它提供了一种跨不同产品或团队细分和比较开发流程的方法。 在分析中,此属性允许过滤和比较不同项目的流程绩效。它有助于回答诸如“哪个项目的周期时间最长?”或“项目 A 的 bug 修复流程与项目 B 相比如何?”之类的问题。这对于“按项目和类型划分的吞吐量”仪表板至关重要。
为何重要
允许对不同项目、产品或团队的开发流程进行细分和比较,从而实现更具针对性的分析。
获取方式
几乎在所有 GitHub Webhook 和 API 负载中的 'repository' 对象中均可获取。具体字段通常为 'repository.full_name' 或 'repository.name'。
示例
my-org/web-appmy-org/api-servicemy-org/data-pipeline
|
|||
|
优先级
Priority
|
分配给开发项的优先级级别,例如 “高”、“中” 或 “低”。 | ||
|
描述
优先级表示工作项的紧急程度或业务重要性。在 GitHub 中,优先级不是原生字段,通常使用标签(例如 “P1-高”、“P2-中”)进行管理。需要一致的标签方案才能可靠地提取此信息。 此属性对于“基于优先级的流动分析”至关重要。它允许分析师验证高优先级项目是否确实比低优先级项目处理得更快,并衡量基于优先级的周期时间差异。这有助于评估优先级划分流程的有效性。
为何重要
可以分析高优先级项目的处理速度是否快于低优先级项目,从而验证优先级策略的有效性。
获取方式
派生自应用于 Issue 或 Pull Request 的 GitHub 标签。这需要统一的优先级标签命名规范。
示例
高中低严重
|
|||
|
开发项类型
DevelopmentItemType
|
开发工作项的分类,例如功能、bug、任务或 epic。 | ||
|
描述
此属性对所做工作的性质进行分类。此类信息通常通过 GitHub 中的标签或特定 issue 模板进行管理。了解工作类型对于设定适当的绩效预期至关重要,因为 bug 修复的预期周期时间可能比新功能短得多。 此属性支持不同工作类型之间的比较分析。它有助于分析 bug 修复是否比新功能处理得更快,或者了解技术债与新开发之间的资源分配情况。它是“按项目和类型划分的吞吐量”仪表板中的关键维度。
为何重要
对工作项进行分类,以便进行性能比较,并分析不同类型的工作(如 Bug 与新功能)在流程中的流转情况。
获取方式
通常源自应用于 issue 或 pull request 的 GitHub 标签。需要一致的标签规范(例如 “type:bug”、“type:feature”)。
示例
Bug新功能 (Feature)任务技术债
|
|||
|
结束时间
EndTimestamp
|
特定开发活动或事件完成的确切日期和时间。 | ||
|
描述
结束时间戳(end timestamp)标志着活动的完成。虽然 GitHub 中的许多事件是瞬间发生的(例如 “Issue 已创建”),但某些活动具有可衡量的持续时间(例如 CI check 运行)。结束时间与开始时间之差即为活动的处理时间。 此属性用于计算“处理时间”指标,这对于了解在代码审查或自动化 check 等不同任务上投入了多少实际精力至关重要。分析处理时间有助于识别耗时过多的低效活动。
为何重要
能够计算各项活动的精确处理时间,有助于区分实际工作时间和空闲等待时间。
获取方式
可在 check run 对象中作为 'completed_at' 找到,或从后续逻辑结束事件的 timestamp 中推导得出。
示例
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
|
|||
|
被分配用户
Assignee
|
被指派处理开发项或特定任务(如 pull request 审查)的用户或开发人员。 | ||
|
描述
此属性识别在给定阶段负责工作的人员。这可以是 issue 的被指派人、pull request 的作者或被请求进行代码审查的审查者。跟踪被指派人是了解资源分配和工作量的关键。 此属性在分析中用于监控开发人员工作负载、识别资源瓶颈以及分析不同团队成员之间的交接效率。可以按被指派人过滤仪表板,以评估个人或团队绩效,并确保工作分配平衡。
为何重要
对于分析开发人员工作负载、团队绩效以及不同团队成员之间交接的效率至关重要。
获取方式
可通过 GitHub API 提供的 Issue、Pull Request 和审查事件的 JSON 负载中的 'assignee' 或 'user' 对象获取。
示例
john.doejane.smithdev-team-lead
|
|||
|
CI 检查状态
CiCheckStatus
|
自动化持续集成 (CI) check 的状态,例如 “passed” 或 “failed”。 | ||
|
描述
此属性反映了针对 pull request 中的代码更改运行的自动化构建、测试和扫描的结果。CI check 是现代开发工作流中关键的质量关卡。 分析此属性有助于了解自动化测试的有效性。失败率高可能表明代码稳定性、测试套件或开发环境存在问题。它支持“CI Checks 已通过”和“CI Checks 已失败”活动,并有助于分析由损坏构建导致的延迟。
为何重要
反映自动质量关卡的成功或失败,提供有关代码质量和 CI 流水线有效性的见解。
获取方式
通过 GitHub Checks 或 Statuses API 从 check run 或状态对象的 “state” 或 “conclusion” 字段中获取。
示例
successfailure待处理error
|
|||
|
Pull Request 编号
PullRequestNumber
|
与开发项关联的 pull request 的唯一标识符。 | ||
|
描述
Pull Request (PR) 是将一组代码更改合并到特定分支的提案。PR 编号将开发活动(如代码推送和审查)关联回主要的开发项或 Issue。 此 ID 对于在更广泛的开发生命周期中跟踪代码集成和审查子流程至关重要。通过它,可以对代码审查过程进行详细分析,包括审查时间、审查中发现的返工循环以及合并率。它将计划阶段(Issue)与实施阶段(PR)连接起来。
为何重要
将 Issue 关联到具体的代码更改和审查流程,从而对代码审查周期及其对整体交付时间的影响进行详细分析。
获取方式
在许多 GitHub API 响应中,可作为 'pull_request' 对象内的 'number' 字段获取,或作为来自 Pull Requests API 的主标识符获取。
示例
12345678910
|
|||
|
交接等待时间
HandoffWaitingTime
|
计算得出的空闲时间,即开发项在不同人员执行的活动之间等待的时间。 | ||
|
描述
此指标衡量一个活动完成到下一个活动开始之间的时间,但仅限于负责人发生变更的情况。例如,从“请求审查”事件到另一位用户执行“审查要求更改”事件之间的时间。 这是识别沟通隔阂和协作问题的关键指标。它支持“关键交接效率”仪表板和“平均交接等待时间”KPI。交接点等待时间长通常是资源受限或通知流程低效的迹象。
为何重要
精准识别不同团队或角色交接时因协作不佳或资源匮乏而导致的延迟,这些往往是效率低下的主要原因。
获取方式
通过识别 'Assignee' 或 'User' 属性发生变化的连续活动,然后测量它们之间的时间间隔来计算。
示例
PT1H15M2天4小时PT25M
|
|||
|
作者
Author
|
创建 issue、pull request 或 commit 的用户。 | ||
|
描述
作者(Author)是开发流程中特定产出物的发起人。例如,issue 的作者是报告 bug 或请求功能的人。pull request 的作者是编写代码的开发人员。 在分析中,作者可用于了解工作来源。例如,分析 bug 报告的作者可能会揭示与特定团队或功能相关的模式。它还可以与被指派人(assignee)结合使用来分析交接模式。
为何重要
识别工作项或代码更改的发起者,这有助于分析返工来源、Bug 报告或功能需求。
获取方式
在 Issue、Pull Request 和 Commit 的 API 响应的主对象内的 'user' 对象中获取。字段通常为 'user.login'。
示例
sara.jonesmike.leeautomation-bot
|
|||
|
最后数据更新
LastDataUpdate
|
指示此 record 数据上次从源系统刷新的 timestamp。 | ||
|
描述
此属性记录最近一次 data 提取或更新的日期和时间。它提供有关被分析数据新鲜度的元数据。这与记录业务事件发生时间的事件时间戳不同。 在分析中,此字段对于了解流程视图的时效性至关重要。它帮助用户了解他们是在查看实时数据还是特定时间点的快照,这对于运营仪表板和监控非常重要。
为何重要
指示 data 的新鲜度,这对于确保分析和仪表板基于最新信息至关重要。
获取方式
此时间戳在数据提取、转换与加载(ETL)过程中生成并添加。
示例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
分支名称
BranchName
|
进行开发项代码更改的 Git 分支名称。 | ||
|
描述
分支是独立的开发路线,旨在处理新功能或修复漏洞,而不影响主代码库。分支名称通常包含有用信息,例如 Issue 编号或工作简述。 分析分支名称有助于理解分支策略以及对开发规范的遵循情况。此外,它还有助于将特定的代码提交与开发项关联起来,从而提供编码活动的完整视图。
为何重要
提供有关特定开发线路的背景信息,并有助于执行和分析分支策略及命名规范。
获取方式
可在推送事件的 'ref' 字段中获取,或在 Pull Request API 响应的 'head' 和 'base' 对象中获取。
示例
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
|
|||
|
处理时间
ProcessingTime
|
计算得出的活动持续时间,代表实际工作时间。 | ||
|
描述
处理时间(Processing Time)是活动开始和结束之间经过的时间。计算方式为“结束时间戳”减去“事件时间戳”。此指标衡量完成一项任务所需的时间,不包括等待任务开始的时间。 分析处理时间有助于确定哪些活动在实际投入方面最耗时。这与包含等待时间的周期时间(cycle time)不同。例如,一次代码审查可能周期时间很长,但处理时间很短,这表明审查人员很忙,PR 正在队列中等待。
为何重要
衡量实际工作时长,帮助区分处理任务的时间与等待任务的时间,这是进行针对性效率提升的关键。
获取方式
通过从单条活动记录的 'EndTimestamp' 中减去 'EventTimestamp' 得出。
示例
PT5M15SPT2H30MP1DT12H
|
|||
|
审批人
Reviewer
|
被请求对 pull request 进行代码审查的用户。 | ||
|
描述
审查人员 (Reviewer) 是被指派检查 Pull Request 中代码更改的开发人员或团队成员,目的是确保代码质量、正确性并符合标准。一个 PR 可以有多名审查人员。 此属性对于分析代码审查流程至关重要。它有助于识别与特定审查人相关的瓶颈,了解审查工作负载分布,并衡量审查人响应请求所需的时间。它是计算“平均代码审查周期时间”KPI 的关键组件。
为何重要
识别参与质量保证流程的人员,从而分析审查工作负载、延迟以及代码审查的整体效率。
获取方式
可通过 GitHub API 提供的 Pull Request 审查事件中的 'requested_reviewers' 数组或 'user' 对象获取。
示例
alex.chenmaria.garciasenior-dev-team
|
|||
|
审核状态
ReviewState
|
pull request 代码审查的结果,例如 “Approved” 或 “Changes Requested”。 | ||
|
描述
此属性捕捉审查者做出的决定。常见状态包括 “APPROVED”(表示代码已准备好合并)和 “CHANGES_REQUESTED”(表示需要返工)。其他状态可能包括 “COMMENTED” 或 “PENDING”。 这是分析返工和质量的关键属性。“CHANGES_REQUESTED” 事件发生频率高,可能表明初始代码质量有问题或需求不明确。它通过识别开发项何时被退回修改,直接支持“返工和回归循环”仪表板。
为何重要
直接反映代码审查过程中的返工循环和质量关卡,有助于锁定低效和质量问题的根源。
获取方式
可通过 GitHub API 提供的 Pull Request 审查对象中的 'state' 字段获取。例如在 'PullRequestReviewEvent' 负载中。
示例
APPROVEDCHANGES_REQUESTEDCOMMENTED
|
|||
|
开发周期时间
DevelopmentCycleTime
|
从开发项创建到其最终部署或关闭所经过的总时间。 | ||
|
描述
这是一个 case 级别的指标,计算为单个开发项从第一个事件(例如 “Issue 已创建”)到最后一个事件(例如 “部署成功” 或 “Issue 已关闭”)之间的时间差。 这是衡量开发流程整体效率最重要的 KPI 之一。它直接支持“整体开发周期时间”仪表板和“平均开发周期时间”KPI。缩短此指标通常是流程改进计划的首要目标。
为何重要
代表开发项端到端的“上市时间”,是衡量整体流程速度和效率的关键绩效指标(KPI)。
获取方式
在 Case 级别计算,通过从最后一个活动的 timestamp 中减去第一个活动的 timestamp 得出。
示例
P5DT6H30MP14DT12HP1DT2H
|
|||
|
提交哈希 (Commit Hash)
CommitHash
|
特定代码 commit 的唯一标识符 (SHA)。 | ||
|
描述
提交哈希 (Commit Hash) 是一个 40 字符的 SHA-1 哈希值,用于唯一标识 Git 中的一次提交。它是特定代码版本的永久 ID。提交是开发过程中变更的原子单位。 尽管粒度极细,但提交哈希提供了最高级别的追溯能力。它允许分析人员将流程事件直接关联到所做的精确代码更改。这对于审计、合规性检查或生产事故的详细根因分析具有不可估量的价值。
为何重要
提供流程步骤与具体代码更改之间最细颗粒度的关联,从而实现完整的审计和调试溯源。
获取方式
可在推送事件负载 ('head_commit.id') 中获取,或通过 Pull Request 或分支的 Commits API 获取。
示例
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
|
|||
|
是否返工
IsRework
|
一个布尔标志,如果某个活动代表流程回退到了先前的阶段,则该标志为 true。 | ||
|
描述
当开发项在流程中倒退时,此标志会被设置为 true。例如,当 pull request 收到 “Changes Requested” 审查,或者当 issue 在关闭后被重新打开时。它是通过分析活动序列得出的。 此属性对于量化浪费和低效至关重要。它直接支持“返工和回归循环”仪表板及“返工率”KPI。通过过滤 “IsRework = true”,分析师可以隔离并调查返工的原因。
为何重要
显式标记构成返工的活动,从而轻松量化、可视化并分析流程低效的原因。
获取方式
这是一个衍生属性。其逻辑包括定义标准流程流,然后标记任何因返回到较早逻辑阶段而发生偏离的活动。
示例
truefalse
|
|||
|
标签
Labels
|
应用于 Issue 或 Pull Request 以进行分类的标签列表。 | ||
|
描述
GitHub 中的标签是向 Issue 和 Pull Request 添加元数据的一种灵活方式。它们可用于表示优先级、工作类型、组件、团队或状态。原始标签列表提供了丰富的非结构化背景信息。 虽然优先级和类型等特定属性是从标签中派生的,但保留完整列表对于即时分析和发现其他流程模式非常有用。它允许根据任何标签组合对 Case 进行灵活的过滤和细分。
为何重要
为工作项分类提供灵活、丰富的元数据来源,支持深度和多维度的分析。
获取方式
可通过 GitHub API 提供的 Issue 和 Pull Request 的 JSON 负载中的 'labels' 数组获取。数组中的每个条目都是一个带有 'name' 字段的对象。
示例
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
|
|||
|
源系统
SourceSystem
|
提取开发流程 data 的来源系统。 | ||
|
描述
此属性标识事件 data 的来源。对于此流程,该值将始终为 “GitHub”。在开发活动跨越多个系统(例如用 Jira 进行规划、用 GitHub 托管代码、用 Jenkins 进行部署)的复杂环境中,此字段用于区分每个事件的来源。 在分析中,它有助于将数据溯源至其起点,以便进行验证和故障排除。它还支持分析跨不同平台的流程,为每项活动提供清晰的背景信息。
为何重要
识别数据来源,这对于数据验证以及分析可能跨越多个集成系统的流程至关重要。
获取方式
这通常是在数据提取、转换和加载 (ETL) 过程中添加的静态值,用于标记记录的来源。
示例
GitHubGitHub Enterprise
|
|||
|
部署环境
DeploymentEnvironment
|
部署的目标环境,例如 “Staging” 或 “Production”。 | ||
|
描述
此属性指定代码的部署位置。跟踪向不同环境的部署是了解从开发到生产发布的完整生命周期的关键。 此属性支持分析部署子流程。它可用于衡量将代码从 staging 提升到生产环境所需的时间,并跟踪向不同环境部署的成功率。这对于了解开发项何时真正“完成”并交付给用户至关重要。
为何重要
区分预生产发布和正式生产发布,这对于衡量真实的“产品上市时间”和分析部署模式至关重要。
获取方式
此信息从 GitHub Deployments API 中检索,通常由 CI/CD 流水线或其他自动化工具触发。
示例
developmentstagingproduction
|
|||
|
项目状态
State
|
issue 或 pull request 的当前状态,例如 “open”、“closed” 或 “merged”。 | ||
|
描述
此属性指示开发项的高级状态。对于 issue,典型状态为 “open” 和 “closed”。对于 pull request,状态包括 “open”、“closed” 和 “merged”。这提供了该项进度的快照。 在分析中,状态用于区分活跃工作与已完成工作。这对于监控正在进行的工作的仪表板(如“活跃开发进度”)至关重要。它还用于定义流程的结束,例如,“merged” 或 “closed” 状态可能表示 case 的完成。
为何重要
清晰指示工作项当前是处于进行中还是已完成状态,这是进行生命周期分析和监控活动工作的基础。
获取方式
可直接在 GitHub API 提供的 Issue 和 Pull Request 的 JSON 负载中的 'state' 字段获取。
示例
开启已关闭merged
|
|||
软件开发生命周期活动
| 活动 | 描述 | ||
|---|---|---|---|
|
CI 检查通过
|
代表针对 pull request 中的代码运行的自动化 check(如构建、单元测试或静态分析)成功完成。此 event 是从 GitHub Actions 等系统报告的 check 状态中推导出来的。 | ||
|
为何重要
这个自动化质量关卡对于确保代码稳定性至关重要。失败或运行时间过长可能会成为交付流水线中的重大瓶颈。
获取方式
从 GitHub Checks API 或 Statuses API 推断得出。Check run 或状态更新报告为 'success',或以 'success' 结论 'completed'。
捕获
通过 Checks API 监控相关 check suite 的 “success” 结论。
事件类型
inferred
|
|||
|
Pull Request 已合并
|
来自 pull request 的已批准代码更改正式集成到目标分支(如 main 或 develop)。这是 pull request 上合并新代码的明确最终操作。 | ||
|
为何重要
这是一个关键里程碑,代表开发和审查的完成。对于许多团队来说,这是自动化部署前的最后一步。
获取方式
从 GitHub Pull Request API 事件流或 Webhook 中捕获。事件评级为 'closed',且 PR 负载的 'merged' 属性为 true。
捕获
监听 pull request 的 “closed” 操作,并检查 “merged” 标志是否为 true。
事件类型
explicit
|
|||
|
Pull Request 已打开
|
表示初始代码块已准备好进行审查和集成。开发人员创建 pull request (PR),建议将更改从其功能分支合并到主分支。这是 GitHub 中的一个明确 event。 | ||
|
为何重要
这是一个关键里程碑,标志着初始开发阶段的结束以及审查和集成流水线的开始。它是分别分析开发周期和审查周期的关键。
获取方式
从 GitHub Pull Request API 事件流或 Webhook 中捕获。事件动作为 'opened'。
捕获
通过 webhook 或 API 轮询监听 pull request 的 “opened” 操作。
事件类型
explicit
|
|||
|
Pull Request 已批准
|
审查人员已正式批准 Pull Request 中的更改,表明其符合质量和功能标准。当审查人员提交状态为“approve”的审查意见时,系统会捕获此事件。 | ||
|
为何重要
这是合并前的一个关键质量关卡和重大里程碑。从 PR 创建到达到此状态所需的时间是衡量审查流程效率的关键 KPI。
获取方式
当提交状态为 'APPROVED' 的审查意见时,从 GitHub Pull Request API 或 Webhook 中捕获。
捕获
过滤 Pull Request 审查提交事件中状态为 'APPROVED' 的记录。
事件类型
explicit
|
|||
|
问题已关闭
|
开发项被视为已完成,相应的 issue 已正式关闭。这可以在链接的 pull request 合并时自动发生,也可以由团队成员手动执行。 | ||
|
为何重要
此活动作为开发项流程的明确终点。这对于计算端到端周期时间至关重要。
获取方式
这是从 GitHub Issues API 事件流中捕获的明确事件。事件类型为 “closed”。
捕获
通过 webhook 或 API 轮询监听 issue 的 “closed” 事件。
事件类型
explicit
|
|||
|
问题已创建
|
标志着开发项生命周期的开始,代表正式创建任务、错误或功能请求。当用户在 GitHub 仓库中创建新 issue 时,系统会明确捕捉到此 event。 | ||
|
为何重要
这是流程的主要起始活动,对于衡量总开发周期时间和了解初始工作来源至关重要。
获取方式
这是从 GitHub Issues API 事件流中捕获的明确事件。给定 issue 编号的事件类型通常为 “opened”。
捕获
通过 webhook 或 API 轮询监听 issue 的 “opened” 事件。
事件类型
explicit
|
|||
|
CI 检查失败
|
代表针对 pull request 中的代码运行的自动化 check 失败,例如构建错误或单元测试失败。这是从 GitHub Actions 等系统报告的失败状态中推导出来的。 | ||
|
为何重要
此活动突出了需要开发人员干预的技术质量问题,从而形成了返工循环。分析失败频率可以指导本地测试或代码质量的改进。
获取方式
从 GitHub Checks API 或 Statuses API 推断得出。Check run 或状态更新报告为 'failure',或以 'failure' 结论 'completed'。
捕获
通过 Checks API 监控相关 check suite 的 “failure” 结论。
事件类型
inferred
|
|||
|
Issue 已重新打开
|
先前已关闭的 Issue 被重新激活,通常是因为修复不彻底或发现了回归。这是一个明确的事件,它会重启该开发项的生命周期。 | ||
|
为何重要
这标志着一个重大的返工循环,表明可能存在“生产环境缺陷逃逸”或修复不彻底。跟踪其频率是衡量软件整体质量的关键手段。
获取方式
这是从 GitHub Issues API 事件流中捕获的明确事件。事件类型为 “reopened”。
捕获
通过 webhook 或 API 轮询监听 issue 的 “reopened” 事件。
事件类型
explicit
|
|||
|
代码已推送到 PR
|
代表对提交审查的代码进行了更新,可能是作为初始 PR 的一部分,也可能是为了响应审查反馈。每当有新 commit 推送到与已打开 pull request 关联的分支时,系统都会捕捉到此 event。 | ||
|
为何重要
跟踪这些事件对于识别返工循环至关重要。审查后的多次推送表明需要进行更改,这会影响整体周期时间。
获取方式
这是 pull request 时间轴中的一个明确事件,通常标记为添加了 commit。它可以通过 “push” webhook 捕获,也可以通过监控与 PR 关联的 commit 来捕获。
捕获
跟踪与已打开 pull request 关联的分支上的 “push” 事件。
事件类型
explicit
|
|||
|
分支已创建
|
代表 issue 的实际开发工作开始,开发人员从主代码库创建新分支。这是一个明确的 event,在向仓库推送新分支时捕获,分支名称通常包含 issue 编号。 | ||
|
为何重要
表示从计划到实际编码的转换。测量 Issue 创建与此事件之间的时间有助于分析开发人员的接手时间和初始待办积压延迟。
获取方式
通过 GitHub Git API 或监听 'branch' 类型 'create' 事件的 Webhook 捕获。通常需要通过命名规范(如 'feature/issue-123')将分支名称关联到 Issue。
捕获
解析新分支的 “create” webhook event,并将其与 issue 关联。
事件类型
explicit
|
|||
|
审查要求修改
|
审查人员已完成代码审查,并确定在批准 Pull Request 之前需要进行修改。审查人员正式提交状态为“request_changes”的审查意见。 | ||
|
为何重要
此事件明确发出了返工循环信号。分析其发生频率有助于精准发现质量问题、不明确的需求或需要对开发人员进行培训的领域。
获取方式
当提交状态为 'CHANGES_REQUESTED' 的审查意见时,从 GitHub Pull Request API 或 Webhook 中捕获。
捕获
过滤 Pull Request 审查提交事件中状态为 'CHANGES_REQUESTED' 的记录。
事件类型
explicit
|
|||
|
已请求审查
|
pull request 的作者正式要求特定的团队成员或团队审查其代码。这是 GitHub UI 或 API 中的一项明确操作,会触发向被请求审查者的通知。 | ||
|
为何重要
此活动标志着向代码审查流程移交的正式开始。从此时点到提交审查之间的时间有助于衡量审查者的响应速度和潜在瓶颈。
获取方式
从 GitHub Pull Request API 事件流或 Webhook 中捕获。事件动作为 'review_requested'。
捕获
监听 pull request 的 “review_requested” 操作。
事件类型
explicit
|
|||
|
部署成功
|
代码更改已成功部署到特定环境,例如预发布(staging)或生产环境。此 event 通常通过 GitHub Deployments API 捕获,通常在合并后由 GitHub Action 触发。 | ||
|
为何重要
标志着代码从仓库转换到线上环境。跟踪这一过程对于衡量从创意到投产的完整交付周期至关重要。
获取方式
通过 Deployments API 捕获。外部服务或 GitHub Action 创建部署,然后将其状态更新为 'success'。
捕获
通过 webhook 监控部署状态 event,检查是否为 “success” 状态。
事件类型
inferred
|
|||