您的软件开发生命周期数据模板
您的软件开发生命周期数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- 提取指南
软件开发生命周期属性
| 名称 | 说明 | ||
|---|---|---|---|
|
开发项
DevelopmentItemId
|
单个开发工作单元的唯一标识符,例如功能、缺陷修复或任务。这是主要的案例标识符。 | ||
|
说明
开发项ID用于跟踪工作项从创建到最终部署的全过程。它将分支创建、提交、拉取请求、审查和部署等所有相关活动关联为一个完整的流程实例。 在分析中,该ID用于计算开发任务的端到端周期时间。它可以重建功能或缺陷修复的完整历程,从而详细分析单个工作项的瓶颈、返工循环和流程差异。
为什么重要
这是流程挖掘的关键标识,将所有相关开发事件连接到同一个案例中,以便准确呈现和分析端到端软件开发生命周期。
获取位置
通常是GitHub中的问题编号或拉取请求编号。可以从问题或拉取请求相关Webhook事件负载或API响应的“number”字段中提取。
示例
101PR-2345TASK-812
|
|||
|
开始时间
EventTimestamp
|
特定开发活动或事件发生的准确日期和时间。 | ||
|
说明
该时间戳标志着活动的开始。它对于按时间顺序排列事件、重建每个开发项的流程至关重要。这些时间戳的顺序及其间隔用于分析流程绩效。 在分析中,该属性对于计算所有基于时间的指标至关重要,包括周期时间、处理时间和等待时间。它可以识别步骤之间的延迟,并为瓶颈分析和绩效监控仪表板提供所需数据。
为什么重要
该时间戳对于正确排列事件以及计算周期时间、瓶颈持续时间等所有绩效指标至关重要。
获取位置
通常位于GitHub API和Webhook针对问题、拉取请求、提交等对象返回的JSON负载中的“created_at”或“updated_at”字段。
示例
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
|
|||
|
活动
ActivityName
|
软件开发生命周期中发生的特定事件或任务的名称。 | ||
|
说明
活动名称描述开发流程中的单个步骤,例如“创建问题”“向PR推送代码”“拉取请求已批准”或“部署成功”。这些事件构成开发项端到端流程的步骤序列。 该属性是流程挖掘的基础,用于构建流程图。分析活动的顺序、频率和持续时间,可以揭示实际流程、识别常见路径、突出偏差并定位瓶颈。
为什么重要
该属性构成流程图的基础,可用于呈现和分析开发生命周期中的事件顺序。
获取位置
根据Webhook事件负载中的“action”字段推导,例如问题的“opened”和“closed”,或根据事件类型本身推导,例如“PushEvent”和“PullRequestReviewEvent”。
示例
创建问题打开拉取请求向PR推送代码请求审查拉取请求已合并
|
|||
|
代码库
RepositoryName
|
开展开发活动的代码库名称。 | ||
|
说明
代码库充当项目或产品标识符,包含特定应用或组件的全部代码、问题和拉取请求。它可以用于划分和比较不同产品或团队的开发流程。 在分析中,该属性支持筛选和比较不同项目的流程绩效,帮助回答“哪个项目的周期时间最长?”或“项目A的缺陷修复流程与项目B相比如何?”等问题。它是“按项目和类型统计吞吐量”仪表板的重要维度。
为什么重要
支持划分和比较不同项目、产品或团队的开发流程,从而开展更有针对性的分析。
获取位置
几乎所有GitHubWebhook和API负载的“repository”对象中都包含该信息。具体字段通常为“repository.full_name”或“repository.name”。
示例
my-org/web-appmy-org/api-servicemy-org/data-pipeline
|
|||
|
优先级
Priority
|
分配给开发项的优先级,例如“High”“Medium”或“Low”。 | ||
|
说明
优先级表示工作项的紧迫程度或业务重要性。在GitHub中,优先级不是原生字段,通常通过标签管理(例如“P1-High”“P2-Medium”)。要可靠提取此信息,需要统一的标签规范。 此属性是“Priority-Based Flow Analysis”的基础。它可帮助分析人员验证高优先级项目是否确实比低优先级项目处理得更快,并根据优先级衡量周期时间差异,从而评估优先级管理流程的有效性。
为什么重要
支持分析高优先级项目是否比低优先级项目处理得更快,从而验证优先级策略的有效性。
获取位置
来源于应用于Issue或Pull Request的GitHub标签。需要采用标准化的优先级标签规范。
示例
高中等低严重
|
|||
|
分配用户
Assignee
|
负责处理开发项或特定任务的用户或开发人员,例如拉取请求审查。 | ||
|
说明
该属性用于标识特定阶段的负责人,可以是问题的受派人、拉取请求作者,或受邀进行代码审查的审查者。跟踪受派人对于了解资源分配和工作负载至关重要。 在分析中,该属性用于监控开发人员工作负载、识别资源瓶颈,以及分析不同团队成员之间的交接效率。仪表板可以按受派人筛选,用于评估个人或团队绩效,并确保工作分配均衡。
为什么重要
对于分析开发人员工作负载、团队绩效以及不同团队成员之间的交接效率至关重要。
获取位置
可在GitHub API返回的问题、拉取请求和审查事件JSON负载中的“assignee”或“user”对象内找到。
示例
john.doejane.smithdev-team-lead
|
|||
|
开发项类型
DevelopmentItemType
|
开发工作项的分类,例如功能、缺陷、任务或史诗。 | ||
|
说明
该属性用于对工作性质进行分类。此信息通常通过GitHub中的标签或特定问题模板进行管理。了解工作类型对于设定合理的绩效预期至关重要,因为缺陷修复的预期周期时间可能远短于新功能开发。 该属性支持不同工作类型之间的对比分析,帮助判断缺陷修复是否比新功能处理得更快,或了解技术债务与新开发之间的资源分配情况。它是“按项目和类型统计吞吐量”仪表板的关键维度。
为什么重要
对工作项进行分类,便于比较绩效,并分析不同类型的工作(例如缺陷与功能)如何流经流程。
获取位置
通常来源于应用于Issue或Pull Request的GitHub标签。需要统一的标签命名规范(例如“type:bug”“type:feature”)。
示例
BugFeatureTask技术债务
|
|||
|
结束时间
EndTimestamp
|
特定开发活动或事件完成的准确日期和时间。 | ||
|
说明
结束时间戳标志着活动完成。GitHub中的许多事件是瞬时发生的,例如“创建问题”,但有些活动具有可衡量的持续时间,例如运行CI检查。结束时间与开始时间之差,即为活动的处理时间。 该属性用于计算“ProcessingTime”指标,对于了解代码审查或自动化检查等任务投入了多少实际工作时间至关重要。分析处理时间有助于识别耗时过长的低效活动。
为什么重要
支持精确计算活动的处理时间,帮助区分实际工作时间和空闲等待时间。
获取位置
可以在检查运行对象的“completed_at”字段中找到,也可以根据后续逻辑上表示完成的事件时间戳推导。
示例
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
|
|||
|
CI检查状态
CiCheckStatus
|
自动化持续集成(CI)检查的状态,例如“passed”或“failed”。 | ||
|
说明
此属性反映针对Pull Request代码变更运行的自动化构建、测试和扫描结果。CI检查是现代开发工作流中的关键质量关卡。 分析此属性有助于了解自动化测试的有效性。较高的失败率可能表明代码稳定性、测试套件或开发环境存在问题。它支持“CI Checks Passed”和“CI Checks Failed”活动,并有助于分析构建失败造成的延迟。
为什么重要
表示自动化质量关卡是否通过,帮助了解代码质量和CI流水线的有效性。
获取位置
通过GitHub Checks或Statuses API,从检查运行或状态对象的“state”或“conclusion”字段获取。
示例
成功失败待处理错误
|
|||
|
Commit哈希
CommitHash
|
特定代码Commit的唯一标识符(SHA)。 | ||
|
说明
Commit哈希是一个40位SHA-1哈希值,用于在Git中唯一标识Commit。它是特定代码版本的永久ID。Commit是开发流程中的最小变更单元。 虽然粒度很细,Commit哈希却提供了最高级别的可追溯性。它可以将流程事件直接关联到实际发生的代码变更,对于审计、合规或生产事故的详细根因分析非常有价值。
为什么重要
在流程步骤与确切代码变更之间建立最细粒度的关联,为审计和调试提供完整的可追溯性。
获取位置
可从推送事件负载(“head_commit.id”)获取,也可通过Commits API获取Pull Request或分支的Commit信息。
示例
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
|
|||
|
Pull Request编号
PullRequestNumber
|
与开发项关联的Pull Request唯一标识符。 | ||
|
说明
Pull Request(PR)是将一组代码变更合并到指定分支的提案。Pull Request编号可将代码推送、评审等开发活动关联回主要开发项或Issue。 此ID对于跟踪整个开发生命周期中的代码集成和评审子流程至关重要。它支持对代码评审流程进行详细分析,包括评审耗时、评审期间发现的返工周期以及合并率,并连接规划阶段(Issue)与实施阶段(PR)。
为什么重要
将Issue关联到具体代码变更和评审流程,支持详细分析代码评审周期及其对整体交付时间的影响。
获取位置
在许多GitHub API响应中,可从“pull_request”对象内的“number”字段获取;也可作为Pull Requests API返回的主要标识符获取。
示例
12345678910
|
|||
|
交接等待时间
HandoffWaitingTime
|
开发项在不同人员执行的活动之间等待所产生的空闲时间。 | ||
|
说明
此指标衡量一项活动完成到下一项活动开始之间的时间,但仅统计负责人发生变化的情况。例如,某用户发出“Review Requested”事件后,另一用户发出“Changes Requested in Review”事件之间的时间。 这是识别沟通缺口和协作问题的关键指标。它支持“Critical Handoff Efficiency”仪表板和“Average Handoff Waiting Time”KPI。交接点等待时间过长,通常意味着资源受限或通知流程效率低下。
为什么重要
定位不同团队或角色交接过程中因协作不佳或资源不可用造成的延迟,这些问题通常是效率低下的主要来源。
获取位置
识别“Assignee”或“User”属性发生变化的连续活动,然后计算两项活动之间的时间差。
示例
1小时15分钟2天4小时25分钟
|
|||
|
作者
Author
|
创建Issue、Pull Request或Commit的用户。 | ||
|
说明
作者是开发流程中特定工件的发起人。例如,Issue的作者是报告缺陷或提出功能需求的人员;Pull Request的作者是编写代码的开发人员。 在分析中,作者可用于了解工作的来源。例如,分析缺陷报告作者可能发现与特定团队或功能相关的模式。结合受派人信息,还可分析交接模式。
为什么重要
识别工作项或代码变更的发起人,有助于分析返工、缺陷报告或功能需求的来源。
获取位置
可在GitHub API针对Issue、Pull Request和Commit的响应主对象中的“user”对象内获取。字段通常为“user.login”。
示例
sara.jonesmike.leeautomation-bot
|
|||
|
最后更新时间
LastDataUpdate
|
表示该记录数据最近一次从源系统刷新时间的时间戳。 | ||
|
说明
该属性记录最近一次数据提取或更新的日期和时间,提供有关待分析数据新鲜度的元数据。它不同于事件时间戳,后者记录业务事件实际发生的时间。 在分析中,该字段对于了解流程视图的时效性至关重要。它可以帮助用户判断当前查看的是实时数据,还是特定时间点的快照,这对于运营仪表板和监控十分重要。
为什么重要
表示数据的新鲜度,对于确保分析和仪表板基于最新信息至关重要。
获取位置
该时间戳在数据提取、转换和加载(ETL)过程中生成并添加。
示例
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
分支名称
BranchName
|
开发项代码变更所在Git分支的名称。 | ||
|
说明
分支是独立的开发线路,用于开发新功能或修复缺陷,同时不影响主代码库。分支名称通常包含有用信息,例如Issue编号或工作的简短描述。 分析分支名称有助于了解分支策略以及开发规范的执行情况,也有助于将具体代码Commit关联到开发项,从而完整呈现编码活动。
为什么重要
提供具体开发线路的上下文,有助于执行和分析分支策略及命名规范。
获取位置
推送事件中可从“ref”字段获取;也可从Pull Request API响应中的“head”和“base”对象获取。
示例
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
|
|||
|
工作项状态
State
|
Issue或Pull Request的当前状态,例如“open”“closed”或“merged”。 | ||
|
说明
此属性表示开发项的高层级状态。对于Issue,常见状态为“open”和“closed”;对于Pull Request,状态包括“open”“closed”和“merged”。它反映了工作项的当前进展。 在分析中,状态用于区分进行中的工作与已完成的工作。对于“Active Development Progress”等监控持续进行工作的仪表板,这一属性必不可少。它还可用于定义流程结束,例如“merged”或“closed”可能表示案例已完成。
为什么重要
清晰表明工作项当前处于进行中还是已完成,这是生命周期分析和进行中工作监控的基础。
获取位置
可直接从GitHub API返回的Issue和Pull Request JSON负载中的“state”字段获取。
示例
已打开已关闭已合并
|
|||
|
开发周期时间
DevelopmentCycleTime
|
从创建开发项到最终部署或关闭所经过的总时间。 | ||
|
说明
这是案例级指标,计算单个开发项从第一个事件(例如“Issue Created”)到最终事件(例如“Deployment Succeeded”或“Issue Closed”)之间的时间差。 这是衡量开发流程整体效率的关键KPI之一。它直接支持“Overall Development Cycle Time”仪表板和“Average Development Cycle Time”KPI。降低该指标通常是流程改进计划的主要目标。
为什么重要
表示开发项端到端的“上市时间”,是衡量流程整体速度和效率的关键KPI。
获取位置
在案例级别计算,用最后一个活动的时间戳减去第一个活动的时间戳。
示例
5天6小时30分钟14天12小时1天2小时
|
|||
|
是否返工
IsRework
|
布尔标记;如果某项活动表示回退到之前的流程阶段,则值为true。 | ||
|
说明
当开发项在流程中向后移动时,此标记设为true,例如Pull Request收到“Changes Requested”评审,或Issue关闭后重新打开。该标记通过分析活动序列得出。 此属性对于量化浪费和低效至关重要。它直接支持“Rework and Regression Loops”仪表板和“Rework Rate”KPI。通过筛选“IsRework = true”,分析人员可以单独识别并调查返工原因。
为什么重要
明确标记构成返工的活动,便于量化、可视化和分析流程低效的原因。
获取位置
这是一个派生属性。其逻辑是先定义标准流程,然后标记偏离流程、返回较早逻辑阶段的活动。
示例
truefalse
|
|||
|
标签
Labels
|
应用于Issue或Pull Request、用于分类的标签列表。 | ||
|
说明
GitHub标签是为Issue和Pull Request添加元数据的灵活方式,可用于标识优先级、工作类型、组件、团队或状态。完整的原始标签列表提供了丰富的非结构化上下文。 虽然Priority和Type等特定属性来源于标签,但保留完整列表有助于临时分析和发现其他流程模式。您可以根据任意标签组合灵活筛选和细分案例。
为什么重要
提供灵活且丰富的元数据来源,用于对工作项进行分类,支持深入、多维度的分析。
获取位置
可从GitHub API返回的Issue和Pull Request JSON负载中的“labels”数组获取。数组中的每个项目都是包含“name”字段的对象。
示例
Bug,界面,高优先级Feature,后端,需要文档技术债务,重构
|
|||
|
源系统
SourceSystem
|
提取开发流程数据的系统。 | ||
|
说明
该属性用于标识事件数据的来源。对于此流程,其值通常固定为“GitHub”。在更复杂的环境中,如果开发活动跨越多个系统,例如使用Jira进行规划、GitHub管理代码、Jenkins负责部署,该字段可用于区分每个事件的来源。 在分析中,它有助于追溯数据来源,以便验证和排查问题。同时,它也支持分析跨多个平台的流程,为每项活动提供清晰背景。
为什么重要
标识数据来源,对于数据验证以及分析跨多个集成系统的流程至关重要。
获取位置
通常是在数据提取、转换和加载(ETL)过程中添加的静态值,用于标记记录来源。
示例
GitHubGitHub Enterprise
|
|||
|
评审人
Reviewer
|
被请求对Pull Request执行代码评审的用户。 | ||
|
说明
评审人是负责检查Pull Request代码变更的开发人员或团队成员,检查内容包括质量、正确性和规范遵循情况。一个Pull Request可以有多名评审人。 此属性对于分析代码评审流程至关重要。它有助于识别与特定评审人相关的瓶颈、了解评审工作量分布,并衡量评审人响应请求所需的时间。它也是计算“Average Code Review Cycle Time”KPI的关键组成部分。
为什么重要
识别参与质量保证流程的人员,支持分析评审工作量、延迟以及代码评审的整体效率。
获取位置
可从GitHub API的“requested_reviewers”数组或Pull Request评审事件中的“user”对象获取。
示例
alex.chenmaria.garciasenior-dev-team
|
|||
|
评审状态
ReviewState
|
Pull Request代码评审的结果,例如“Approved”或“Changes Requested”。 | ||
|
说明
此属性记录评审人作出的决定。常见状态包括“APPROVED”,表示代码已准备合并;以及“CHANGES_REQUESTED”,表示需要返工。其他状态可能包括“COMMENTED”或“PENDING”。 这是分析返工和质量的关键属性。“CHANGES_REQUESTED”事件频繁出现,可能表明初始代码质量存在问题,或需求不够明确。它直接支持“Rework and Regression Loops”仪表板,用于识别开发项何时被退回修改。
为什么重要
直接反映代码评审流程中的返工循环和质量关卡,有助于定位效率低下和质量问题的来源。
获取位置
可从GitHub API的Pull Request评审对象中的“state”字段获取,例如“PullRequestReviewEvent”负载。
示例
已批准要求修改已评论
|
|||
|
部署环境
DeploymentEnvironment
|
部署的目标环境,例如“Staging”或“Production”。 | ||
|
说明
此属性指定代码的部署位置。跟踪不同环境中的部署,是了解从开发到生产发布完整生命周期的关键。 此属性支持分析部署子流程,可用于衡量代码从预发布环境推广到生产环境所需的时间,并跟踪不同环境中的部署成功率。它对于判断开发项何时真正“完成”并交付给用户至关重要。
为什么重要
区分预生产发布和生产发布,这对于衡量真实的“上市时间”以及分析部署模式至关重要。
获取位置
此信息从GitHub Deployments API获取,该API通常由CI/CD流水线或其他自动化流程触发。
示例
开发环境预发布环境生产环境
|
|||
软件开发生命周期活动
| 活动 | 说明 | ||
|---|---|---|---|
|
CI检查通过
|
表示针对拉取请求代码运行的自动化检查成功完成,例如构建、单元测试或静态分析。此事件根据GitHub Actions等系统报告的检查状态推断得出。 | ||
|
为什么重要
这一自动化质量关卡对于确保代码稳定性至关重要。检查失败或运行时间过长,可能成为交付流程中的重要瓶颈。
获取位置
根据GitHub Checks API或Statuses API推断。当检查运行或状态更新报告“success”,或报告“completed”且结论为“success”时,即视为通过。
采集
监控Checks API,查找相关检查套件的“success”结论。
事件类型
inferred
|
|||
|
关闭问题
|
开发项被视为完成,相应问题正式关闭。关联的拉取请求合并后,问题可能自动关闭,也可以由团队成员手动关闭。 | ||
|
为什么重要
此活动是开发项流程的明确终点,对于计算端到端周期时间至关重要。
获取位置
这是从GitHub Issues API事件流中捕获的明确事件。事件类型为“closed”。
采集
通过Webhook或API轮询监听问题上的“closed”事件。
事件类型
explicit
|
|||
|
创建问题
|
标志着开发项生命周期的开始,代表任务、缺陷或功能请求的正式创建。当用户在GitHub代码库中创建新问题时,系统会明确记录此事件。 | ||
|
为什么重要
这是流程的主要起始活动,对于衡量完整开发周期时间和了解工作最初来源至关重要。
获取位置
这是从GitHub Issues API事件流中捕获的明确事件。对于指定的问题编号,事件类型通常为“opened”。
采集
通过Webhook或API轮询监听问题上的“opened”事件。
事件类型
explicit
|
|||
|
打开拉取请求
|
表示首批代码已准备好进行审查和集成。开发人员创建拉取请求(PR),提议将功能分支中的变更合并到主分支。这是GitHub中的明确事件。 | ||
|
为什么重要
这是一个关键里程碑,标志着初始开发阶段结束,审查和集成流程开始。它有助于分别分析开发周期和审查周期。
获取位置
从GitHub Pull Request API事件流或Webhook中捕获。事件操作为“opened”。
采集
通过Webhook或API轮询监听拉取请求的“opened”操作。
事件类型
explicit
|
|||
|
拉取请求已合并
|
拉取请求中已批准的代码变更正式集成到目标分支,例如main或develop。这是拉取请求上的明确最终操作,用于纳入新代码。 | ||
|
为什么重要
这是一个关键里程碑,表示开发和审查完成。对许多团队而言,这是自动部署前的最后一步。
获取位置
从GitHub Pull Request API事件流或Webhook中捕获。事件操作为“closed”,且拉取请求负载中的“merged”属性为true。
采集
监听拉取请求的“closed”操作,并检查“merged”标志是否为true。
事件类型
explicit
|
|||
|
拉取请求已批准
|
审查者正式批准拉取请求中的变更,表示其符合质量和功能标准。当审查者以“approve”状态提交审查结果时,系统会记录此事件。 | ||
|
为什么重要
这是合并前的关键质量关卡和重要里程碑。从PR创建到达到此状态所需的时间,是衡量审查流程效率的重要KPI。
获取位置
当审查以“APPROVED”状态提交时,从GitHub Pull Request API或Webhook中捕获。
采集
筛选状态为“APPROVED”的拉取请求审查提交事件。
事件类型
explicit
|
|||
|
CI检查失败
|
表示针对拉取请求代码运行的自动化检查失败,例如构建错误或单元测试失败。此事件根据GitHub Actions等系统报告的失败状态推断得出。 | ||
|
为什么重要
此活动突出显示需要开发人员介入的技术质量问题,并形成返工循环。分析失败频率,有助于改进本地测试或代码质量。
获取位置
根据GitHub Checks API或Statuses API推断。当检查运行或状态更新报告“failure”,或报告“completed”且结论为“failure”时,即视为失败。
采集
监控Checks API,查找相关检查套件的“failure”结论。
事件类型
inferred
|
|||
|
创建分支
|
表示问题进入主动开发阶段,即开发人员从主代码库创建新分支。这是推送新分支到代码库时捕获的明确事件,分支名称通常包含问题编号。 | ||
|
为什么重要
表示流程从规划转入主动编码。衡量问题创建与此事件之间的时间,有助于分析开发人员开始处理的时间和初始积压延迟。
获取位置
通过GitHub Git API或监听分支类型为“branch”的“create”事件的Webhook捕获。通常需要依据“feature/issue-123”等命名约定,将分支名称与问题关联。
采集
解析新分支的“create”Webhook事件,并将其与问题关联。
事件类型
explicit
|
|||
|
向PR推送代码
|
表示提交审查的代码发生更新,可能属于初始PR,也可能是对审查反馈的响应。每当向与开放拉取请求关联的分支推送新提交时,系统都会记录此事件。 | ||
|
为什么重要
跟踪这些事件对于识别返工循环至关重要。审查后多次推送通常表示需要修改,会影响整体周期时间。
获取位置
这是拉取请求时间线中的明确事件,通常标记为已添加提交。可以从“push”Webhook中捕获,也可以通过监控与PR关联的提交来获取。
采集
跟踪与开放拉取请求关联的分支上的“push”事件。
事件类型
explicit
|
|||
|
审查中要求修改
|
审查者完成代码审查后,认为拉取请求在获批前需要修改。审查者会以“request_changes”状态正式提交审查结果。 | ||
|
为什么重要
此事件明确表示出现返工循环。分析其发生频率,有助于定位质量问题、需求不清或开发人员培训不足等原因。
获取位置
当审查以“CHANGES_REQUESTED”状态提交时,从GitHub Pull Request API或Webhook中捕获。
采集
筛选状态为“CHANGES_REQUESTED”的拉取请求审查提交事件。
事件类型
explicit
|
|||
|
请求审查
|
拉取请求作者正式邀请指定团队成员或团队审查代码。这是GitHub界面或API中的明确操作,会向受邀审查者发送通知。 | ||
|
为什么重要
此活动标志着代码审查交接正式开始。从该活动到提交审查结果之间的时间,有助于衡量审查者的响应速度和潜在瓶颈。
获取位置
从GitHub Pull Request API事件流或Webhook中捕获。事件操作为“review_requested”。
采集
监听拉取请求的“review_requested”操作。
事件类型
explicit
|
|||
|
部署成功
|
代码变更已成功部署到特定环境,例如预发布环境或生产环境。此事件通常通过GitHub Deployments API捕获,往往由合并后的GitHub Action触发。 | ||
|
为什么重要
标志着代码从代码库进入运行环境。跟踪此事件对于衡量从想法到生产环境的完整交付周期至关重要。
获取位置
通过Deployments API捕获。外部服务或GitHub Action创建部署,然后将其状态更新为“success”。
采集
通过Webhook监控部署状态事件,查找状态为“success”的记录。
事件类型
inferred
|
|||
|
重新打开问题
|
此前已关闭的问题被重新激活,通常是因为修复不充分或发现了回归问题。这是会重新启动开发项生命周期的明确事件。 | ||
|
为什么重要
这表示出现了重要的返工循环,可能意味着“生产缺陷逃逸”或修复不完整。跟踪其发生频率,是衡量整体软件质量的重要指标。
获取位置
这是从GitHub Issues API事件流中捕获的明确事件。事件类型为“reopened”。
采集
通过Webhook或API轮询监听问题上的“reopened”事件。
事件类型
explicit
|
|||
提取指南
提升您的SDLC:即时定位低效环节
将周期时间缩短30%,简化您的GitHub开发流程。
无需信用卡,几分钟即可完成设置。