您的软件开发生命周期数据模板
您的软件开发生命周期数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- ServiceNow DevOps数据提取指南
软件开发生命周期属性
| 名称 | 说明 | ||
|---|---|---|---|
| 开发项 DevelopmentItem | 用于标识单个工作单元的唯一标识符,例如在开发生命周期中推进的功能、缺陷或任务。 | ||
| 说明 开发项是主要案例标识,代表正在跟踪的独立工作单元。它将该项从初始构想到规划、开发、测试和部署的所有活动关联起来。 在流程挖掘分析中,此属性是重建每个工作项端到端历程的基础。它有助于可视化流程路径、计算总周期时间,并识别各项功能或缺陷修复的流程变体。日志中的每个事件都必须关联到一个开发项,才能构建连贯的流程图。 重要性 这是将所有相关开发活动关联到同一流程实例的核心标识符,因此可以分析每个工作项的完整生命周期。 获取途径 此标识符通常是管理用户故事、缺陷或任务的表中的主键,例如ServiceNow中的“rm_story”“rm_bug”或“task”表。 示例 STRY0010015BUG0034092TASK0050118 | |||
| 开始时间 EventTime | 表示特定活动或事件发生时间的准确时间戳。 | ||
| 说明 此属性记录开发生命周期中每项活动的日期和时间,是按时间顺序排列事件及开展所有时间分析的基础。 在流程挖掘中,开始时间用于计算活动间隔、识别等待时间和衡量流程总周期时间。它是分析绩效的仪表板(如SDLC端到端周期时间分析)以及计算代码审查交付周期等关键绩效指标的重要依据。 重要性 此时间戳对于正确排列事件,以及计算周期时间、持续时间和等待时间等绩效指标至关重要。 获取途径 通常可在审计跟踪或任务表的系统生成时间戳字段中找到,例如“sys_updated_on”或“sys_created_on”。 示例 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:15:00Z | |||
| 活动名称 ActivityName | 发生的具体开发生命周期事件名称,例如“开发开始”或“完成代码审查”。 | ||
| 说明 此属性记录软件开发生命周期中完成的各个里程碑或任务名称。这些活动构成流程的连续步骤,从创建到部署。 分析活动的顺序和频率是流程挖掘的主要用途。通过分析,您可以构建流程图、发现步骤之间的瓶颈,并找出不符合规范或效率低下的流程变体。活动列表涵盖设计、开发、测试和部署等关键阶段。 重要性 此属性定义流程图中的步骤,支持分析流程路径、发现瓶颈,并找出偏离标准SDLC的情况。 获取途径 通常通过将状态变更、事件记录或审计跟踪条目映射到标准化活动名称列表来确定。例如,“状态”字段变为“进行中”时,可映射为“开发开始”。 示例 开发开始提交代码QA测试完成已部署到生产环境 | |||
| 数据上次更新时间 LastDataUpdate | 表示事件日志数据上次从源系统刷新的时间戳。 | ||
| 说明 此属性记录数据集上次从ServiceNow DevOps提取或更新的时间,适用于整个数据集,而非单个事件。 此时间戳对于了解分析数据的新鲜度至关重要。它能让用户了解流程洞察的时效性,并帮助安排数据刷新。在仪表板上显示此信息,可为所有指标和可视化内容提供背景,确保决策依据及时的数据。 重要性 为了解数据的时效性提供重要背景,帮助用户判断流程分析所用数据是否为最新。 获取途径 此时间戳在数据提取过程中生成并添加,用于记录提取执行时间。 示例 2023-11-15T08:00:00Z | |||
| 源系统 SourceSystem | 标识数据的提取来源,本例中的源系统为ServiceNow DevOps。 | ||
| 说明 此属性指定事件数据的来源系统。对于此流程,该值始终为“ServiceNow DevOps”。 虽然该值看似固定,但明确记录源系统对于数据治理至关重要;在合并来自Jira或Azure DevOps等多个系统的数据时尤其如此。它能清楚说明数据来源,并帮助排查数据质量或提取问题。 重要性 确保数据可追溯,并有助于维护数据完整性,尤其是在整合多个开发工具的数据时。 获取途径 这是一个固定值,应在数据提取和转换过程中添加。 示例 ServiceNow DevOps | |||
| 优先级 DevelopmentItemPriority | 分配给开发项的优先级,例如“高”“中”或“低”。 | ||
| 说明 此属性根据业务紧迫程度对开发项分类。优先级有助于团队聚焦最关键的任务,通常用于管理SLA和相关方预期。 在流程挖掘中,优先级是比较分析的重要维度。您可以按优先级筛选流程图,查看高优先级项目是否采用更快或不同的处理路径。它也是“高优先级功能交付时间”仪表板和KPI的重要依据,可用于验证关键项目是否确实得到加速处理。 重要性 支持按不同优先级筛选和比较流程,帮助确认高优先级项目是否得到更快、更高效的处理。 获取途径 这是ServiceNow中任务相关表的标准字段,通常名为“priority”。 示例 1 - 严重2 - 高3 - 中等4 - 低 | |||
| 分配组 AssignmentGroup | 活动发生时负责该开发项的团队或小组。 | ||
| 说明 此属性用于标识工作项所属团队,例如“前端开发”“后端服务”或“QA团队”。工作项推进过程中,通常会在不同分配组之间交接。 跟踪分配组对于了解跨职能协作和工作交接至关重要。它有助于发现工作在团队间流转时出现的系统性延误,也支持分析团队绩效和工作量,并识别整体流程中的瓶颈团队。 重要性 跟踪负责工作的团队,以便分析团队绩效、平衡工作量,并评估团队间交接效率。 获取途径 此信息存储在“assignment_group”字段中,这是ServiceNow任务相关表的标准字段。 示例 平台工程移动应用团队质量保证DevOps | |||
| 受分派开发人员 AssignedDeveloper | 活动发生时,受分派到该开发项的开发人员或用户的姓名或ID。 | ||
| 说明 此属性标识负责执行特定任务或活动的人员。开发项在不同阶段和团队之间流转时,此属性可能发生变化。 此属性对于分析资源分配、工作负荷和交接情况至关重要,可直接支持“开发人员工作负荷与交接”仪表板和“每位开发人员的活动量”KPI。跟踪此字段的变化,可以衡量交接时间,并发现开发人员之间或开发与QA团队之间的协作瓶颈。 重要性 这是基于资源开展分析的必要信息,包括工作负荷分配、交接效率,以及识别团队特有的绩效模式。 获取途径 此信息通常存储在ServiceNow任务相关表的“assigned_to”字段中。 示例 David MillerAnna WilliamsJames Brown | |||
| 受影响的模块/组件 ModuleComponentAffected | 开发项涉及的具体软件模块、应用程序或组件。 | ||
| 说明 此属性按受影响的系统部分对开发工作进行分类,例如特定微服务、UI组件或后端应用程序。 按模块或组件细分流程,对于发现局部瓶颈至关重要。“按组件查看瓶颈分析”仪表板和“各组件平均阶段耗时”KPI会使用此属性,定位代码库中的哪些部分持续伴随较长的开发周期、较高的返工率或较频繁的部署失败。这有助于将改进工作集中在最需要的地方。 重要性 支持按应用程序或组件细分分析,帮助定位系统特定部分的瓶颈或质量问题。 获取途径 这通常是自定义字段,或指向配置管理数据库(CMDB)的引用字段,用于将工作项关联到“cmdb_ci”记录。请参阅ServiceNow DevOps文档。 示例 计费服务用户身份验证界面报表数据库API网关 | |||
| 开发项周期时间 DevelopmentItemCycleTime | 从创建开发项到最终关闭或部署所经过的总时间。 | ||
| 说明 此属性是一个计算指标,表示单个开发项的端到端耗时。计算方法是针对每个案例,求首次活动与最后一次活动时间戳之间的差值。 这是衡量整个SDLC流程绩效的核心指标,也是“SDLC平均周期时间”KPI的直接依据。它从整体上衡量流程速度和效率。按时间以及优先级、团队等维度分析此指标,有助于跟踪流程改进举措的成效。 重要性 表示工作项的端到端总耗时,是衡量整体流程效率和速度的关键指标。 获取途径 源系统中没有此字段。流程挖掘工具会针对每个案例,用最大StartTime减去最小StartTime进行计算。 示例 15天4小时3天12小时32天8小时 | |||
| 开发项状态 DevelopmentItemState | 事件发生时开发项的状态,例如“Open”(打开)、“In Progress”(进行中)或“Closed”(已关闭)。 | ||
| 说明 此属性反映开发项在ServiceNow中的正式状态。活动是从流程中提取的步骤,而状态表示该项在系统工作流中的正式阶段。 状态通常是提取活动的依据,可用于验证数据,也可用于创建更简洁的高层流程视图。例如,分析各状态的耗时,可以从不同于分析活动间耗时的角度发现瓶颈。状态也有助于识别停滞或已解决的事项。 重要性 提供工作项在系统中的正式状态,通常可作为提取活动的依据,也可用于数据验证和高层状态分析。 获取途径 这是ServiceNow中任务相关表的标准字段,通常名为“state”或“stage”。 示例 待处理进行中待测试已完成并关闭 | |||
| 开发项类型 DevelopmentItemType | 工作项的分类,例如“功能”“缺陷”“技术债务”或“任务”。 | ||
| 说明 此属性用于区分SDLC流程中的不同工作类型。例如,修复严重缺陷的流程可能不同于开发新功能的流程,且速度可能更快。 按工作项类型分析流程,有助于更细致地了解绩效,并回答诸如“缺陷的返工率是否高于新功能?”或“技术债务的周期时间是否在可接受范围内?”等问题。与一概而论的流程视图相比,这种细分能带来更深入的洞察。 重要性 区分功能和缺陷等不同工作类型,因为它们可能采用不同的流程路径、优先级和预期耗时。 获取途径 可根据记录的源表(例如“rm_story”与“rm_bug”)确定,也可通过通用任务表中的“type”字段确定。 示例 功能缺陷Task技术调研 | |||
| 是否返工 IsRework | 布尔标记。如果某项活动属于返工循环(例如测试后返回开发阶段),则值为true。 | ||
| 说明 这是一个派生属性,用于识别流程返回较早阶段后发生的活动。例如,同一事项在“QA测试完成”后又发生“开发已开始”活动,就会被标记为返工。 此标记对于量化和可视化返工至关重要,可直接用于“返工与驳回流程分析”仪表板,并用于计算“测试后返工率”KPI。标记这些事件后,分析人员可以轻松筛选并分析返工的频率、原因及其对整体周期时间的影响。 重要性 此标记便于量化和分析返工,帮助衡量流程质量并找出重复工作的根本原因。 获取途径 流程挖掘工具会分析每个案例的活动顺序,检测流程中的回退,从而计算此属性。 示例 truefalse | |||
| 提交ID CommitId | 与开发工作相关联的源代码提交唯一标识符。 | ||
| 说明 此属性将开发项直接关联到Git等源代码仓库中的具体代码变更,并在发生“代码已提交”活动时记录。 在流程挖掘中,提交ID通过关联流程数据和工程数据,丰富分析内容。分析人员可以追溯问题部署对应的具体代码变更,也可以将代码复杂度指标与开发周期时间进行关联分析,从而深入开展技术层面的根因分析。 重要性 将流程事件关联到具体代码变更,以便结合流程指标和代码级详情深入分析根因。 获取途径 此信息由ServiceNow DevOps与Git或SVN等源代码管理系统的集成记录,并存储在与开发项关联的表中。 示例 a1b2c3d4e5f6f0e9d8c7b6a59a8b7c6d5e4f | |||
| 结束时间 EventEndTime | 表示活动完成时间的准确时间戳。对于瞬时事件,该值与开始时间相同。 | ||
| 说明 此属性记录开发生命周期中每项活动完成的日期和时间,尤其适用于“完成代码审查”或“QA测试”等可衡量耗时的活动。 在流程挖掘中,同时记录开始和结束时间,才能准确计算活动处理时间,并将其与活动间的等待时间区分开来。这有助于判断延误是由任务耗时过长,还是等待资源造成的。对于“触发构建”等瞬时事件,结束时间可以与开始时间相同。 重要性 支持准确计算活动处理时间,帮助区分实际工作耗时和等待耗时。 获取途径 此值可能需要推算,可以使用下一项活动的开始时间戳,也可以从源系统中单独的“结束日期”字段获取(如果有)。 示例 2023-10-26T18:05:00Z2023-10-28T11:20:15Z2023-11-02T10:00:00Z | |||
| 计划发布版本 PlannedReleaseVersion | 计划交付开发项的目标软件发布版本。 | ||
| 说明 此属性将开发项关联到特定的计划发布版本,例如“版本2.3”或“2023年第四季度发布”。它是项目管理和发布规划的重要组成部分。 在流程挖掘中,此属性对于“发布计划执行情况监控”仪表板至关重要。通过比较实际完成日期与计划发布日期,团队可以衡量计划执行情况、识别可能错过发布的事项,并分析发布延误的原因。它将底层开发流程与高层业务目标直接关联起来。 重要性 将开发工作关联到具体发布版本,以便分析计划执行情况,以及流程延误对发布时间安排的影响。 获取途径 此信息通常存储在“release”或“planned_release”字段中,且往往引用ServiceNow中的发布管理表。请参阅ServiceNow DevOps文档。 示例 v3.4.12024年第一季度发布Phoenix项目上线 | |||
| 返工原因 ReworkReason | 对开发项测试后需要返工的原因进行分类或说明。 | ||
| 说明 当某个事项未通过QA或UAT时,此属性会记录失败原因,例如特定缺陷类别、需求理解有误或环境问题。 这些信息为“返工与驳回流程分析”仪表板提供重要背景。分析人员不仅能了解是否发生返工,还能查明返工原因,从而有针对性地改进,例如完善需求定义、加强单元测试或提高测试环境稳定性,以降低整体返工率。 重要性 提供返工原因的定性信息,帮助有针对性地改进流程、提升质量并减少反复返工。 获取途径 测试失败时,原因可能记录在“close_notes”字段中,也可能存储在专用的“rework_reason”自定义字段中。请参阅ServiceNow DevOps文档。 示例 需求理解有误回归缺陷性能测试未通过UI/UX问题 | |||
| 部署状态 DeploymentStatus | 表示部署活动的结果,通常为“成功”或“失败”。 | ||
| 说明 此属性记录部署到特定环境的结果,是了解发布流程可靠性和稳定性的关键信息。 此属性是“部署成功与失败趋势”仪表板和“部署失败率”KPI的必要数据。通过分析部署失败的频率和趋势,组织可以发现测试、基础设施或发布协调方面的潜在问题,并据此改进软件交付的质量和可靠性。 重要性 直接衡量部署活动是否成功,是计算部署失败率和分析发布稳定性的关键数据。 获取途径 此状态通常记录在部署跟踪任务或与ServiceNow DevOps集成的CI/CD流水线执行记录中。 示例 成功失败已完成,但有警告 | |||
软件开发生命周期活动
| 活动 | 说明 | ||
|---|---|---|---|
| QA测试完成 | 表示质量保证团队已完成该开发项的测试。通常根据开发项状态从测试阶段变为“待UAT”或“已完成”等状态推断。 | ||
| 重要性 此里程碑标志着一个重要质量关卡完成,是后续用户验收测试或发布准备等阶段的前提。 获取途径 根据状态从测试状态(如“QA中”)变为测试后的状态(如“待UAT”或“已解决”)的时间戳推断。 采集 根据状态从“测试中”变为后续状态的时间戳确定。 事件类型 inferred | |||
| UAT已批准 | 表示业务相关方在用户验收测试后正式批准了开发项。这是一个关键里程碑,可根据状态变更推断,例如从“UAT中”变为“待发布”或“已批准”。 | ||
| 重要性 这是开发项获准部署到生产环境前的最终业务审批,也是重要的质量与治理检查点。 获取途径 根据开发项记录中表示UAT成功完成的状态转换推断,并记录在该项的活动历史中。 采集 根据状态从“UAT”变为已批准或可发布状态推断。 事件类型 inferred | |||
| 创建开发项 | 此活动表示在ServiceNow中创建了新的开发项,例如用户故事、缺陷或大型需求。通常在向相关表(如Story [rm_story]表)插入新记录时,会明确记录此事件。 | ||
| 重要性 这是SDLC流程的主要开始事件,可用于衡量端到端总周期时间,并跟踪初始需求的接收情况。 获取途径 在Story [rm_story]、Epic [rm_epic]或Defect [rm_defect]等开发相关表中创建记录时,相关信息会记录在sys_audit或sys_history_line表中。创建时间戳通常保存在记录本身。 采集 取自开发项记录的创建时间戳。 事件类型 explicit | |||
| 完成代码审查 | 此活动表示已完成同行代码审查,通常与拉取请求或合并请求相关联。可通过DevOps集成明确捕获此事件,也可根据相关记录的状态变更推断。 | ||
| 重要性 这是关键的质量关卡。分析其耗时有助于发现审查流程中的瓶颈,而这也是SDLC延误的常见原因。 获取途径 可从ServiceNow Git集成中拉取请求记录的“已合并”或“已完成”事件获取,也可根据开发项状态变为“代码审查完成”推断。 采集 与工作项关联的拉取请求合并时记录。 事件类型 explicit | |||
| 已部署到生产环境 | 此事件标志着部署已成功完成并进入生产环境。CI/CD工具报告流水线成功完成时,ServiceNow DevOps会明确捕获此事件。 | ||
| 重要性 这是SDLC流程的主要成功结束点,标志着价值流完成,也是计算总周期时间的关键依据。 获取途径 取自Pipeline Execution [sn_devops_pipeline_execution]记录或其关联的Stage Execution Run中的“completion_status”。结束时间的状态为“Success”时,即表示发生此事件。 采集 生产部署流水线成功完成时记录。 事件类型 explicit | |||
| 开发开始 | 此活动表示开发人员开始为开发项编写代码或进行实现。通常根据开发项状态变为“进行中”“开发中”或“编码中”来推断。 | ||
| 重要性 这是一个重要里程碑,标志着创造价值的构建阶段开始。它对于衡量开发人员交付周期和代码审查周期至关重要。 获取途径 根据开发项记录(如Story [rm_story])中的“状态”字段更新为“进行中”或等效状态的时间戳推断。 采集 根据状态变为“进行中”或类似值的时间戳确定。 事件类型 inferred | |||
| 部署失败 | 表示开发项未能成功部署到生产环境。CI/CD流水线报告失败时,ServiceNow DevOps会明确捕获此事件。 | ||
| 重要性 这是一个关键的失败结束点。分析其发生频率和原因,对于提升发布稳定性、降低部署失败率至关重要。 获取途径 取自Pipeline Execution [sn_devops_pipeline_execution]记录中的“completion_status”。结束时间的状态为“Failed”时,即表示发生此事件。 采集 生产部署流水线报告失败状态时记录。 事件类型 explicit | |||
| QA测试开始 | 标志着正式质量保证测试阶段开始。通常根据开发项状态变为“QA中”“测试中”或“待测试”等值推断。 | ||
| 重要性 此活动标志着工作从开发团队移交给QA团队,可用于衡量测试阶段耗时并发现测试能力方面的瓶颈。 获取途径 根据开发项记录(如Story或Defect)中的“状态”字段更新为QA专属状态的时间戳推断。 采集 根据状态变为“测试中”或等效状态的时间戳确定。 事件类型 inferred | |||
| UAT开始 | 表示用户验收测试开始,业务相关方将在此阶段验证功能。可根据状态变为“UAT”“UAT中”或“用户验收测试”推断此事件。 | ||
| 重要性 此阶段对于确保开发的功能满足业务需求至关重要。分析其耗时有助于发现用户参与度不足或需求不匹配等问题。 获取途径 根据开发项记录中的状态转换推断。客户的状态模型需包含单独的UAT状态。 采集 根据状态变为“UAT”推断。 事件类型 inferred | |||
| 发现返工 | 表示测试期间发现问题,需要将开发项退回开发阶段。可通过观察流程中的回退来推断,例如状态从“QA中”变回“进行中”。 | ||
| 重要性 跟踪返工对于了解质量问题和流程低效至关重要。此活动频繁发生,说明开发过程或需求说明可能存在问题。 获取途径 通过分析sys_audit或sys_history_line表中“状态”字段的历史记录推断。从较后阶段的状态(如“测试中”)变为较早阶段的状态(如“进行中”),即表示发生返工。 采集 根据状态回退推断,例如“测试中”->“进行中”。 事件类型 inferred | |||
| 已准备发布 | 此活动表示开发项已通过所有质量关卡,并纳入特定版本。可根据开发项关联到发布记录,或状态变为“待部署”推断。 | ||
| 重要性 此步骤表示开发项在技术和功能方面均已完成。在此状态停留的时间可能代表等待预定部署窗口的排队时间。 获取途径 根据“状态”字段变为“待发布”推断,也可跟踪开发项记录中的“发布”字段何时填入或更新。 采集 根据状态变更或与发布记录的关联推断。 事件类型 inferred | |||
| 开发项已取消 | 表示开发项尚未完成便已终止。这是一种替代结束状态,通常根据该项状态设为“已取消”或“未完成关闭”推断。 | ||
| 重要性 跟踪取消情况有助于发现资源浪费,并了解范围变更或优先级调整的原因,也能更完整地呈现流程可能产生的结果。 获取途径 根据开发项记录中的“状态”字段更新为“已取消”等未完成的终止状态时的时间戳推断。 采集 根据状态变为“已取消”或等效终止状态推断。 事件类型 inferred | |||
| 开始部署到生产环境 | 此活动标志着部署流水线开始向生产环境部署。生产阶段的CI/CD流水线开始执行时,ServiceNow DevOps会明确捕获此事件。 | ||
| 重要性 这标志着生命周期最后一个阶段的开始,该阶段往往最为关键。跟踪此活动有助于分析部署耗时并发现自动化机会。 获取途径 在Stage Execution Run [sn_devops_stage_execution]表中明确记录,并筛选与生产环境相关的阶段。 采集 取自Pipeline Execution中生产部署阶段的开始时间。 事件类型 explicit | |||
| 提交代码 | 表示开发人员将代码提交到与开发项关联的版本控制系统代码库。ServiceNow DevOps会从Git或GitHub等集成SCM工具中明确捕获此类事件。 | ||
| 重要性 跟踪代码提交可细致呈现开发进度和活动频率,并帮助将具体代码变更与其所属开发项关联起来。 获取途径 此事件会明确记录在ServiceNow DevOps的Commits [sn_devops_commit]表中,该表由集成的源代码管理系统通过webhook填充。 采集 收到SCM工具发送的提交webhook时记录。 事件类型 explicit | |||
| 触发构建 | 此事件表示CI/CD流水线构建开始,通常由代码提交触发。ServiceNow DevOps会将其记录为流水线执行,并关联到发起构建的开发项。 | ||
| 重要性 此活动连接开发与自动化测试或部署。分析代码提交到构建开始之间的时间,可以发现CI/CD流程中的延误。 获取途径 集成的CI/CD工具(如Jenkins、Azure DevOps)启动构建时,事件会明确记录在Pipeline Execution [sn_devops_pipeline_execution]表中。 采集 取自Pipeline Execution表中记录的开始时间。 事件类型 explicit | |||
| 设计开始 | 表示正在为开发项制定技术设计或解决方案架构。通常根据开发项记录中的状态字段推断,例如状态变为“设计”或“方案设计”。 | ||
| 重要性 分析设计阶段的耗时,有助于在开发开始前发现需求转化和解决方案规划中的瓶颈。 获取途径 根据开发项记录(如Story [rm_story])中的状态转换推断。查找“状态”或自定义“阶段”字段变为设计相关值的记录。 采集 根据状态变为“设计”或类似状态推断。 事件类型 inferred | |||
数据提取指南
步骤
- 了解状态模型:创建报表前,请记录开发项状态字段中与所需活动对应的具体值(例如Story
[rm_story]表或Defect[rm_defect]表中的值)。例如,状态值“In Progress”可能对应“开发已开始”活动。 - 进入报表创建页面:登录ServiceNow实例。在筛选导航器中,依次进入
Reports > View / Run,然后点击Create a report按钮。 - 创建状态变更报表:先创建一份报表,用于记录由状态变更触发的活动。配置如下:
- 报表名称:
ProcessMind - State Change Events - 来源类型:
Table - 表:
Audit [sys_audit] - 类型:
List - 配置列:添加
Document key、Created on、Table name、Field name、Old value和New value。 - 筛选:将
Table name设为某个开发项表(例如Story),并将Field name设为状态字段(例如State)。在Created on字段上添加日期筛选,指定所需时间范围。
- 报表名称:
- 创建开发项新增报表:新建一份报表,记录开发项的初始创建事件。
- 报表名称:
ProcessMind - Item Creation Events - 来源类型:
Table - 表:
Story [rm_story](或您的主要开发项表) - 类型:
List - 配置列:添加所需属性列,例如
数字、Created on、Assigned to、Priority、State等。 - 筛选:在
Created on字段上添加日期筛选。
- 报表名称:
- 创建代码提交报表:创建一份报表,记录明确的DevOps代码提交事件。
- 报表名称:
ProcessMind - Commit Events - 来源类型:
Table - 表:
Commit [sn_devops_commit] - 类型:
List - 配置列:添加
Work item、Commit time、Author等列。 - 筛选:在
Commit time字段上添加日期筛选。
- 报表名称:
- 创建构建和部署报表:按照上一步的操作,为
Build [sn_devops_build]和Deployment [sn_devops_deployment]表创建报表。这些表包含Build Triggered、Deployment to Production Started、Deployed to Production和Deployment Failed活动的记录。 - 导出所有报表:逐一运行创建的报表。点击每份报表的上下文菜单图标(三个点或向下箭头),选择
Export > CSV或Export > Excel,并保存所有文件。 - 合并和转换数据:在电子表格程序中打开导出的文件,或使用数据准备工具。将所有文件中的数据手动合并到一个工作表中。创建所需的事件日志列(
DevelopmentItem、ActivityName、EventTime等),并映射来源列中的数据。例如,将审计报表中的Document key和Story报表中的数字映射到DevelopmentItem列。 - 映射活动名称:根据来源数据创建
ActivityName列。对于状态变更报表,使用记录的状态模型,将New value条目映射为活动名称(例如,将状态“Testing”映射为“QA Testing Started”)。对于其他报表,为每行指定固定的活动名称(例如,将提交导出文件中的所有行设为“Code Committed”)。 - 完成并保存:为所有行添加
SourceSystem和LastDataUpdate列,并填入固定值。确保所有时间戳格式一致。将最终合并文件保存为单个CSV文件,即可上传到ProcessMind。
配置
- 所需表:提取数据主要需要
Audit [sys_audit]表(用于推断事件)、具体的开发项表(例如Story [rm_story]、Defect [rm_defect]),以及ServiceNow DevOps核心表:Commit [sn_devops_commit]、Build [sn_devops_build]和Deployment [sn_devops_deployment]。 - 关键筛选条件:最重要的是日期范围,所有报表都应使用
Created on、Commit time或开始时间等时间戳字段,并采用一致的日期范围。对于sys_audit报表,必须按Table name(例如rm_story)和Field name(例如state)筛选,仅保留相关状态变更。 - 日期范围建议:建议提取3至6个月的数据,以获得有代表性的数据集,同时避免影响性能。对于规模较大的系统,可按月分批提取。
- 定义状态模型:您需要清楚了解组织使用的工作项状态模型,才能将
sys_audit表中记录的状态值正确映射到相应业务活动,例如“QA Testing Started”或“UAT Approved”。 - 前提条件:执行提取的用户需要具备
report_user角色或同等权限,才能创建和运行报表;还需要对上述DevOps表和应用开发表拥有读取权限。必须安装ServiceNow DevOps插件,并确保其已与SCM和CI/CD工具集成。
查询示例 sql
/*
This extraction method uses the ServiceNow report builder UI. The following sections describe the configuration for each report that must be created and exported.
The exported data must then be manually combined and transformed into a single event log file.
*/
---
-- REPORT 1: Item Creation Events
---
Report_Name: ProcessMind - Item Creation Events
Source_Table: rm_story
Report_Type: List
Columns:
- Number (maps to DevelopmentItem)
- sys_created_on (maps to EventTime)
- 'Development Item Created' (create a formula or static column for ActivityName)
- Assigned to (maps to AssignedDeveloper)
- Priority (maps to DevelopmentItemPriority)
- State (maps to DevelopmentItemState)
- cmdb_ci (maps to ModuleComponentAffected)
- Type (maps to DevelopmentItemType)
- Assignment group (maps to AssignmentGroup)
Filters:
- sys_created_on ON Last 6 months
---
-- REPORT 2: Inferred State Change Events
---
Report_Name: ProcessMind - State Change Events
Source_Table: sys_audit
Report_Type: List
Columns:
- documentkey (maps to DevelopmentItem)
- sys_created_on (maps to EventTime)
- newvalue (maps to ActivityName, requires translation)
- user (maps to AssignedDeveloper)
ActivityName_Mapping_Logic (Example):
- WHEN newvalue IS '[Your Design State]' THEN 'Design Started'
- WHEN newvalue IS '[Your In Progress State]' THEN 'Development Started'
- WHEN newvalue IS '[Your QA State]' THEN 'QA Testing Started'
- WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your In Progress State]' THEN 'Rework Identified'
- WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your UAT State]' THEN 'QA Testing Completed'
- WHEN newvalue IS '[Your UAT State]' THEN 'UAT Started'
- WHEN newvalue IS '[Your UAT Approved State]' THEN 'UAT Approved'
- WHEN newvalue IS '[Your Release Ready State]' THEN 'Prepared For Release'
- WHEN newvalue IS '[Your Cancelled State]' THEN 'Development Item Cancelled'
Filters:
- tablename = 'rm_story'
- fieldname = 'state'
- sys_created_on ON Last 6 months
---
-- REPORT 3: Code Commit Events
---
Report_Name: ProcessMind - Commit Events
Source_Table: sn_devops_commit
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- commit_time (maps to EventTime)
- 'Code Committed' (create a formula or static column for ActivityName)
- author.name (maps to AssignedDeveloper)
Filters:
- commit_time ON Last 6 months
---
-- REPORT 4: Build Events
---
Report_Name: ProcessMind - Build Events
Source_Table: sn_devops_build
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- start_time (maps to EventTime)
- 'Build Triggered' (create a formula or static column for ActivityName)
Filters:
- start_time ON Last 6 months
---
-- REPORT 5: Deployment Events
---
Report_Name: ProcessMind - Deployment Events
Source_Table: sn_devops_deployment
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- start_time (maps to EventTime for 'Started' activities)
- end_time (maps to EventTime for 'Completed' or 'Failed' activities)
- state (maps to ActivityName, requires translation)
ActivityName_Mapping_Logic:
- WHEN state IS 'in_progress' THEN 'Deployment to Production Started'
- WHEN state IS 'successful' THEN 'Deployed to Production'
- WHEN state IS 'failed' THEN 'Deployment Failed'
Filters:
- start_time ON Last 6 months
- [Filter for production deployments based on your environment configuration]
---
-- Additional events like 'Code Review Performed' may require a separate report
-- on a table like `sn_devops_pull_request` if available and configured.
--- 步骤
- 前提条件:确保您可以通过网络访问ServiceNow实例,并已获得具备读取权限的专用服务账户(可从
itil和sn_devops.viewer角色开始配置)。该账户需要能够访问rm_story、sys_audit和sn_devops_*架构等表。 - 安装ServiceNow ODBC驱动程序:从ServiceNow支持门户下载适用于您操作系统的ServiceNow ODBC驱动程序,并按照提供的说明完成安装。
- 配置DSN:在运行查询的计算机上设置新的系统DSN(数据源名称)。在ODBC数据源管理器中添加ServiceNow驱动程序,并填写实例URL(例如
yourinstance.service-now.com)、用户名和密码。 - 使用SQL客户端连接:使用DBeaver、Microsoft SQL Server Management Studio(通过链接服务器)等SQL客户端,或使用带ODBC库的Python等脚本语言,通过已配置的DSN连接ServiceNow。
- 确认状态模型:运行查询前,必须确认组织在开发项表(例如
rm_story、rm_defect)的state字段中使用的准确值。提供的查询使用“In Progress”或“In QA”等常见示例,您需要将其替换为实际使用的值。 - 自定义SQL查询:将提供的SQL查询复制到客户端中。修改查询开头的占位值,包括提取开始日期,以及与开发生命周期活动对应的具体状态值。
- 执行查询:通过ODBC连接对ServiceNow数据库运行完整SQL查询。所需时间可能较长,具体取决于日期范围和数据量。
- 检查数据:查询完成后,简要检查返回的数据集。查看各类活动,并确认
DevelopmentItem、ActivityName和EventTime等关键列均已按预期填充。 - 导出为CSV:将完整结果集导出为CSV文件。确保文件采用UTF-8编码,且列标题与ProcessMind所需的属性名称一致,例如
DevelopmentItem、ActivityName和EventTime。 - 准备上传:确保最终CSV文件末尾没有空行,并且
EventTime和LastDataUpdate的日期格式统一且受ProcessMind支持(例如YYYY-MM-DD HH:MM:SS)。
配置
- 前提条件:需要访问已启用DevOps模块的ServiceNow实例,并准备具备所需表读取权限的专用用户账户。客户端计算机上必须安装并配置ServiceNow ODBC驱动程序。
- ODBC驱动程序配置:连接需要实例URL、用户名,以及密码或OAuth令牌。运行复杂查询前,务必测试DSN连接。
- 日期范围筛选:提供的查询包含占位条件
s.sys_created_on >= '2023-01-01',用于限制提取的数据量。强烈建议指定明确的时间范围,例如最近6到12个月,以确保查询耗时可控。 - 自定义状态模型:推断事件的准确性完全取决于查询中的状态模型。您必须将占位状态值(例如
[Your 'In Progress' State Value]、[Your 'In QA' State Value])替换为ServiceNow配置中使用的准确值。状态值区分大小写。 - 工作项表:此查询针对Story表(
rm_story)编写。如果组织还使用Defect(rm_defect)、Enhancement(rm_enhancement)或其他任务类型,必须通过UNION ALL将它们添加到初始的DevItems公用表表达式(CTE)中。 - 性能:直接查询生产环境中的ServiceNow实例可能影响性能。建议在非高峰时段执行大规模提取。对于超大型数据集,可根据
sys_updated_on字段采用增量提取策略。
查询示例 sql
WITH DevItems AS (
-- This CTE selects the base set of development items to analyze.
-- Add other tables like rm_defect or rm_enhancement here using UNION ALL if needed.
SELECT
s.sys_id,
s.number,
s.sys_created_on,
s.sys_updated_on,
s.assigned_to,
s.priority,
s.state,
s.cmdb_ci, -- Module/Component Affected
s.sys_class_name, -- Development Item Type
s.assignment_group,
DATEDIFF(second, s.sys_created_on, s.closed_at) AS cycle_time_seconds
FROM rm_story s
WHERE s.sys_created_on >= '2023-01-01' -- *** Placeholder: Set your desired start date ***
),
StateChanges AS (
-- This CTE unnests the audit trail for state changes, which are used for inferred activities.
SELECT
a.documentkey AS item_sys_id,
a.sys_created_on AS change_time,
a.oldvalue,
a.newvalue,
-- *** Placeholder: Define the numeric order of your states to detect rework. Adjust values and names. ***
CASE a.oldvalue
WHEN '1' THEN 1 -- Open
WHEN '[Your 'Design' State Value]' THEN 2
WHEN '[Your 'In Progress' State Value]' THEN 3
WHEN '[Your 'In QA' State Value]' THEN 4
WHEN '[Your 'In UAT' State Value]' THEN 5
ELSE 0
END AS old_state_order,
CASE a.newvalue
WHEN '1' THEN 1 -- Open
WHEN '[Your 'Design' State Value]' THEN 2
WHEN '[Your 'In Progress' State Value]' THEN 3
WHEN '[Your 'In QA' State Value]' THEN 4
WHEN '[Your 'In UAT' State Value]' THEN 5
ELSE 0
END AS new_state_order
FROM sys_audit a
WHERE a.tablename = 'rm_story' AND a.fieldname = 'state'
)
-- 1. Development Item Created
SELECT
i.number AS DevelopmentItem,
'Development Item Created' AS ActivityName,
i.sys_created_on AS EventTime,
'ServiceNow DevOps' AS SourceSystem,
GETDATE() AS LastDataUpdate,
us.name AS AssignedDeveloper,
i.priority AS DevelopmentItemPriority,
i.state AS DevelopmentItemState,
ci.name AS ModuleComponentAffected,
i.sys_class_name AS DevelopmentItemType,
grp.name AS AssignmentGroup,
i.cycle_time_seconds AS DevelopmentItemCycleTime,
CAST(0 AS BIT) AS IsRework
FROM DevItems i
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id
LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id
LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 2. Design Started
SELECT i.number, 'Design Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Design'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 3. Development Started
SELECT i.number, 'Development Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In Progress'' State Value]' AND sc.old_state_order < 3 -- *** Placeholder: Adjust state value and order ***
UNION ALL
-- 4. Code Committed
SELECT i.number, 'Code Committed', c.committed_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_commit c JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 5. Build Triggered
SELECT i.number, 'Build Triggered', b.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_build b JOIN sn_devops_commit_build cb ON b.sys_id = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 6. Code Review Performed
SELECT i.number, 'Code Review Performed', pr.closed_at, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_pull_request pr JOIN DevItems i ON pr.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE pr.state = 'merged' -- Or 'closed', depending on process
UNION ALL
-- 7. QA Testing Started
SELECT i.number, 'QA Testing Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In QA'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 8. Rework Identified
SELECT i.number, 'Rework Identified', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(1 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.new_state_order < sc.old_state_order AND sc.new_state_order > 1 -- Moved to an earlier state
UNION ALL
-- 9. QA Testing Completed
SELECT i.number, 'QA Testing Completed', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In QA'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***
UNION ALL
-- 10. UAT Started
SELECT i.number, 'UAT Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In UAT'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 11. UAT Approved
SELECT i.number, 'UAT Approved', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In UAT'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***
UNION ALL
-- 12. Prepared For Release
SELECT i.number, 'Prepared For Release', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Ready for Release'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 13. Deployment to Production Started
SELECT i.number, 'Deployment to Production Started', se.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' -- *** Placeholder: Adjust stage name ***
UNION ALL
-- 14. Deployed to Production
SELECT i.number, 'Deployed to Production', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'SUCCESS' -- *** Placeholder: Adjust stage name and result value ***
UNION ALL
-- 15. Deployment Failed
SELECT i.number, 'Deployment Failed', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'FAILURE' -- *** Placeholder: Adjust stage name and result value ***
UNION ALL
-- 16. Development Item Cancelled
SELECT i.number, 'Development Item Cancelled', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Cancelled'' State Value]'; -- *** Placeholder: Adjust state value *** 立即优化您的软件开发生命周期
定位低效环节,将软件开发生命周期周期时间缩短30%或更多。
无需信用卡,立即开始优化