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