您的软件开发生命周期数据模板

GitLab

← 返回改进指南

软件开发生命周期属性 (20) 软件开发生命周期活动 (12) 提取指南 (4)

您的软件开发生命周期数据模板

此综合模板将引导您准备分析软件开发生命周期流程所需的关键数据。模板列出了需要收集的重要属性和跟踪的关键活动，并提供了直接从GitLab提取这些信息的实用指导。借助此资源，您可以更有把握地准备数据，开展有价值的流程挖掘。

建议收集的属性
需要跟踪的关键活动
提取指南

刚接触事件日志？了解如何创建流程挖掘事件日志.

下载模板

软件开发生命周期属性

以下是建议纳入事件日志的数据字段，用于全面分析和优化软件开发生命周期。

3 必需 5 建议 12 可选

	名称	说明
	开发事项 DevelopmentItem	工作单元的唯一标识符，例如功能、缺陷修复或任务，是主要的案例标识符。
说明开发事项代表软件开发生命周期中一项可单独跟踪的工作。它将从创建到最终部署的所有相关活动连接成一个完整案例。在GitLab中，通常使用问题的内部ID（IID）表示，该ID在项目内唯一。按开发事项分析，可以衡量端到端周期时间、识别瓶颈并检查流程遵循情况。这是了解工作从概念到生产环境交付效率的基础。为什么重要这是连接所有流程事件的关键案例标识符，使您能够追踪任意工作项的完整生命周期。获取位置通常是GitLab问题的内部ID（IID）。您可以在Issues API响应的“iid”字段中找到它。示例 1024512PRJ-2345
	开始时间 StartTime	表示活动或事件开始时间的时间戳。
说明 StartTime标记特定活动发生的准确日期和时间。在GitLab事件中，该值来自不同的时间戳字段。例如，“问题已创建”活动的StartTime是问题的“created_at”时间戳，而“合并请求已合并”活动的StartTime是合并请求的“merged_at”时间戳。该时间戳是流程挖掘中的核心时间要素，用于按时间顺序排列事件、计算活动间隔、衡量周期时间，以及分析流程绩效随时间的变化。为什么重要此属性提供事件的时间顺序，对于计算所有基于时间的指标以及了解顺序流至关重要。获取位置从GitLab的各种时间戳字段中提取，例如问题中的“created_at”“updated_at”“closed_at”，以及合并请求中的“merged_at”。示例 2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
	活动 Activity	已发生的具体流程步骤或事件名称，例如“问题已创建”或“合并请求已合并”。
说明 Activity属性记录开发事项经历的各项独立事件。这些事件不会作为单一字段存储在GitLab中，而是从Issues、Merge Requests和CI/CD Pipelines中的各种操作及时间戳字段派生而来。例如，创建问题、推送提交、流水线失败或批准合并请求，都是独立的活动。该属性是构建流程图、可视化工作流以及分析事件顺序和频率的基础。它用于识别偏离、步骤之间的瓶颈和常见流程路径。为什么重要它定义流程图中的步骤，用于可视化和分析端到端开发工作流。获取位置根据GitLab事件流中的事件类型和状态变更派生，或通过解读Issues和Merge Requests中的“created_at”“merged_at”“closed_at”等时间戳字段获得。示例问题已创建开发已开始合并请求已合并流水线失败已部署到生产环境
	严重程度 Severity	开发事项的严重程度，通常用于缺陷或事件。
说明 Severity表示缺陷或问题的影响程度，范围从严重到轻微。GitLab没有原生的严重程度字段，因此几乎总是通过标签实现，例如“severity::1”“severity::2”。该属性是“严重程度升级趋势”仪表板及相关KPI的基础。分析生命周期中的严重程度变化，可以发现最初被低估的问题，或会加剧问题的流程。为什么重要帮助确定工作优先级，并分析高严重程度事项是否得到更快处理。跟踪变化可支持“严重程度升级频率”KPI。获取位置从GitLab问题所应用的“labels”派生。需要通过映射，将“S1”“S2”等标签解释为严重程度级别。示例 1－严重2－高3－中等4－低
	开发事项类型 DevelopmentItemType	开发事项的分类，例如“功能”“缺陷”“任务”或“维护”。
说明该属性对所执行工作的性质进行分类。在GitLab中，通常通过问题标签实现。团队使用标签区分新功能、缺陷修复、技术债务和其他工作类型。按开发事项类型分析，可以比较不同工作类型的流程路径和周期时间。例如，您可以分析缺陷修复是否比功能开发更快，或技术债务任务是否遵循不同的评审流程。为什么重要按工作类型划分流程，有助于识别某些类型的工作是否更容易出现延迟、返工或偏离。获取位置通常从GitLab问题所应用的“labels”派生。需要通过映射逻辑，将特定标签转换为标准化类型。示例 FeatureBugTask技术债务
	结束时间 EndTime	表示活动或事件完成时间的时间戳。
说明 EndTime标记活动完成的准确日期和时间。对于GitLab中的许多原子事件，例如“问题已创建”，EndTime与StartTime相同。对于代码评审等具有持续时间的活动，EndTime表示完成时间，例如最终批准给出的时间。该属性对于准确计算单项活动的持续时间（处理时间）至关重要。通过区分任务实际处理时间和任务之间的等待时间，它有助于开展详细的瓶颈分析。为什么重要支持精确计算活动持续时间（处理时间），这是识别流程低效步骤的关键。获取位置对于原子事件，该值与StartTime相同。对于持续性活动，需要在数据中查找对应的完成事件来推导。示例 2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
	责任人 Assignee	事件发生时分配给问题或合并请求的用户。
说明 Assignee是在流程特定阶段负责工作项的开发人员或用户。在GitLab中，该信息记录在Issue或Merge Request的“assignee”或“assignees”字段中。按Assignee分析对于“开发人员工作负载与资源配置”仪表板至关重要。它有助于了解资源利用率、识别负载过高的个人或团队，并分析不同人员之间的交接。为什么重要记录工作执行者，支持工作负载分析、资源配置效率分析，以及识别由交接造成的延迟。获取位置从GitLab Issues和Merge Requests API响应中的“assignee.username”或“assignees”字段获取。示例 jdoeasmithr.williams
	项目名称 ProjectName	开发事项所属GitLab项目的名称。
说明该属性标识执行工作的具体代码仓库或项目。在GitLab中，每个问题和合并请求都包含在某个项目内。按项目名称分析，可以比较不同产品、组件或服务的绩效，帮助识别哪些项目的SDLC流程更健康，也便于将仪表板筛选到特定关注领域。为什么重要支持按产品、应用或组件划分流程分析，便于开展有针对性的改进工作。获取位置从Project API中的“name”或“path_with_namespace”字段获取，并通过Issues和Merge Requests中的“project_id”关联。示例 platform/api-gatewayfrontend/customer-portalmobile/ios-app
	交接等待时间 HandoffWaitTime	由不同受派人执行的两个连续活动之间的空闲时间。
说明此指标计算一项活动完成与下一项活动开始之间的间隔，且仅在受派人发生变化时计算。例如，它可以衡量开发人员完成工作到审查人员开始代码审查之间的时间。这是“平均交接等待时间”KPI的核心指标，有助于发现资源分配和团队或个人沟通中的隐性低效，突出不属于任何主动工作的延迟。为什么重要量化不同人员或团队交接期间的空闲时间，揭示隐藏延迟和沟通瓶颈。获取位置由流程挖掘工具计算。工具需要分析案例中的连续事件，检查“Assignee”是否不同，然后计算时间差。示例 1天2小时15分钟8小时
	发布版本 ReleaseVersion	与部署关联的计划或实际软件版本标签。
说明此属性用于标识开发项所属的具体软件发布版本。在GitLab中，它可以通过里程碑、受保护标签或Releases功能中的条目关联。这是“发布计划遵循情况跟踪”仪表板的关键数据。通过比较实际部署日期与发布版本对应的计划日期，组织可以衡量计划执行能力，并诊断发布延迟的原因。为什么重要将开发项关联到具体软件发布版本，这对于跟踪发布进度和计划遵循情况至关重要。获取位置数据可以来自GitLab Releases、git标签名称，或用于发布规划的里程碑标题。示例 v1.2.0v3.0.0-beta2023.4.1
	合并请求状态 MergeRequestStatus	事件关联的合并请求状态，例如“已打开”“已合并”或“已关闭”。
说明该属性记录事件发生时Merge Request（MR）的状态。GitLab MR具有明确状态：“opened”“closed”“merged”或“locked”。它与开发事项状态相互独立。跟踪MR状态对于分析SDLC的代码集成阶段至关重要。它直接支持“代码评审周期时间与吞吐量”等仪表板，并帮助定位MR创建、评审、批准和合并之间的延迟。为什么重要呈现代码评审和合并流程的状态，而这通常是SDLC中的关键瓶颈。获取位置从GitLab Merge Requests API响应中的“state”字段获取。示例已打开已合并已关闭已锁定
	周期时间 CycleTime	开发项从第一个活动到最后一个活动所经过的总时间。
说明周期时间是用于衡量案例总持续时间的计算指标。通常，它是单个开发项中第一个事件（例如“Issue已创建”）与最后一个事件（例如“已部署到生产环境”）之间的时间差。这是衡量整体流程效率的核心KPI，也是“SDLC端到端周期时间”等仪表板中的关键指标，可用于跟踪改进效果，并识别可能反映系统性问题的长周期案例。为什么重要这是流程挖掘中的核心KPI，用于衡量开发生命周期的端到端效率。获取位置流程挖掘工具按每个唯一CaseId计算，方法是用最大StartTime减去最小StartTime。示例 10天4小时23小时15分钟35天
	团队名称 TeamName	与项目或责任人关联的开发团队。
说明 Team Name表示负责开发事项的团队或小组。该信息通常不是GitLab中的标准字段，往往根据项目命名约定、群组结构，或通过外部参考表将责任人映射到所属团队来派生。该属性用于从团队层面分析流程绩效。它有助于比较不同团队的效率、工作负载和流程遵循情况，并支持从团队视角查看“阶段瓶颈分析”等仪表板。为什么重要支持跨团队开展绩效分析和流程对比，帮助识别特定团队的瓶颈或最佳实践。获取位置通常通过将项目名称或责任人映射到GitLab之外定义的团队结构来派生，也可以根据GitLab群组层级推断。示例 Frontend-AlphaBackend-ServicesPlatform-Infra
	开发事项状态 DevelopmentItemStatus	事件发生时开发事项的状态，例如“已打开”“进行中”或“已关闭”。
说明该属性反映主要工作项的状态，通常是GitLab中的Issue。GitLab Issue具有“state”字段，值可以是“opened”或“closed”。更细粒度的状态通常通过范围标签管理，例如“Status::Triage”“Status::In-Dev”“Status::In-Review”。跟踪状态变更对于了解案例生命周期至关重要。它有助于识别事项在每种状态中停留的时间，也可用于在“SDLC端到端周期时间”等仪表板中筛选进行中的工作或已完成的工作。为什么重要提供案例状态的快照，支持分析各阶段耗时，并筛选进行中的工作与已完成的工作。获取位置主要状态来自GitLab Issue的“state”字段（“opened”“closed”）。更细粒度的状态通常从标签派生。示例已打开已关闭处理中审核中
	数据最后更新时间 LastDataUpdate	表示该事件数据最近一次从源系统刷新时间的时间戳。
说明该属性记录事件数据最近一次提取或更新到流程挖掘数据集的日期和时间。它不表示事件发生的时间，而表示事件记录最近一次同步的时间。这些信息对于了解数据新鲜度和验证流程分析的时效性至关重要。它有助于确保仪表板和KPI基于最新数据，并提示源系统与分析结果之间可能存在的延迟。为什么重要透明呈现数据新鲜度，确保用户了解流程分析的更新程度。获取位置数据刷新时，由数据提取工具或ETL流程生成并记录该时间戳。示例 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	是否返工 IsRework	用于标识某项活动是否属于返工循环的布尔标记。
说明此计算属性用于标记代表流程倒退的活动，例如测试已经开始后又返回开发阶段。该标记通常通过检测特定活动序列生成，例如同一案例中“开发已开始”事件发生在“流水线失败”或“QA测试已开始”事件之后。此属性直接支持“返工与重新运行分析”仪表板和“测试后的返工率”KPI。您可以据此轻松筛选并量化返工，帮助团队了解返工频率、原因及其对项目周期的影响。为什么重要直接标记并量化返工，便于分析流程低效和质量问题的原因及影响。获取位置流程挖掘工具通过分析每个案例的活动序列，识别表明返工的模式来计算。示例 truefalse
	流水线状态 PipelineStatus	CI/CD流水线运行状态，例如“成功”“失败”或“运行中”。
说明该属性表示与提交或合并请求关联的CI/CD流水线执行结果。GitLab中的常见状态包括“running”“pending”“success”“failed”“canceled”和“skipped”。这些数据是“返工与重跑分析”仪表板的基础。流水线频繁失败可能是返工和延迟的重要来源，分析其频率、位置和影响，对于提升开发效率和代码质量至关重要。为什么重要跟踪自动化构建和测试的成功与失败，突出返工循环以及代码质量或测试自动化方面的问题。获取位置从GitLab CI/CD Pipelines API响应中的“status”字段获取。示例成功失败运行中已取消
	源系统 SourceSystem	标识数据来源的系统。
说明该属性指定流程数据的来源。在此数据模型中，其值始终为“GitLab”。在流程数据可能来自多个系统的环境中，包含此属性至关重要，例如使用Jira进行规划、使用GitLab执行。它支持筛选和分段分析，并有助于维护数据血缘。为什么重要确保数据来源清晰明确，这对于数据治理以及整合多个企业系统的数据至关重要。获取位置这是一个静态值“GitLab”，在数据转换过程中添加。示例 GitLab
	目标分支 TargetBranch	合并请求的目标分支名称。
说明 Target Branch是计划合并变更的分支，例如“main”“develop”，或“release/1.5”等发布分支。这是任何Merge Request的核心信息。按目标分支分析，可以发现合并到不同目标时的流程差异。例如，合并到“main”可能需要更严格的批准流程，周期时间也可能长于合并到功能分支。它还可以帮助区分生产部署与其他类型的代码集成。为什么重要帮助区分不同的开发和发布工作流，因为流程可能会因目标分支不同而存在显著差异。获取位置从GitLab Merge Requests API响应中的“target_branch”字段获取。示例主分支开发分支release/v2.1.0hotfix/user-auth-bug
	里程碑标题 MilestoneTitle	开发项所属里程碑或冲刺的标题。
说明 GitLab中的里程碑用于跟踪特定目标或时间盒内的工作，例如冲刺或发布版本。此属性记录里程碑的名称或标题。借助此属性，您可以在特定冲刺或规划周期内分析流程绩效，了解周期时间是否逐个冲刺缩短，或将流程视图筛选为仅显示与即将发布版本相关的工作。为什么重要将开发工作关联到冲刺或发布等规划周期，从而分析实际绩效是否符合计划时间盒。获取位置取自GitLab Issues或Merge Requests API响应中的“milestone.title”字段。示例 2023年第四季度发布Sprint 23.11阶段1：MVP

必需建议可选

软件开发生命周期活动

以下是需要记录在事件日志中的关键流程步骤和里程碑，用于准确发现流程并识别瓶颈。

4 建议 8 可选

	活动	说明
	合并请求已创建	表示初始开发工作已完成，代码已准备好进行评审和集成。这是GitLab工作流中的核心明确事件，在开发人员新建合并请求（MR）时捕获。
为什么重要这是一个关键里程碑，标志着流程从开发交接到评审和测试。它是分析完整代码评审及CI/CD流水线周期的起点。获取位置这是从merge_requests表中的“created_at”时间戳或通过Merge Requests API明确捕获的事件。采集使用合并请求的“created_at”时间戳。事件类型 explicit
	合并请求已合并	该活动表示代码评审和集成流程已成功完成。当用户将合并请求的分支合并到目标分支时，就会发生这一明确事件。
为什么重要这是一个重要里程碑，表示开发和评审均已完成。它是衡量开发周期时间的终点，也是衡量部署交付周期的起点。获取位置这是从merge_requests表中的“merged_at”时间戳明确捕获的事件。合并时还会生成系统备注。采集使用合并请求的“merged_at”时间戳。事件类型 explicit
	已部署到生产环境	该活动标志着代码已成功部署到线上生产环境，并可供最终用户使用。当GitLab CI/CD流水线中专门负责“deploy to production”的作业成功完成时，系统会捕获这一事件。
为什么重要这是流程的主要结束事件，表示价值已经交付。它对于衡量端到端SDLC总周期时间和发布频率至关重要。获取位置从专门用于生产部署且成功完成的CI/CD作业的“finished_at”时间戳获取。GitLab的Environments功能会明确跟踪此事件。采集使用成功生产部署CI作业中的“finished_at”时间戳。事件类型 explicit
	问题已创建	该活动标志着开发生命周期的开始，表示创建了新的工作项，例如功能、缺陷或任务。当用户在GitLab中创建新问题时，系统会记录创建时间，并明确捕获这一事件。
为什么重要这是端到端流程的主要开始事件。分析从问题创建到部署的耗时，可以完整了解SDLC周期时间。获取位置这是从issues表中的“created_at”时间戳或通过Issues API明确捕获的事件。系统备注也会记录创建事件。采集使用问题的“created_at”时间戳。事件类型 explicit
	代码评审已开始	标志着合并请求的同行评审开始。通常通过首次评审相关操作推断，例如作者以外的其他人发布的第一条评论或讨论串。
为什么重要衡量从MR创建到评审开始的耗时，可以揭示排队延迟。缩短等待时间是减少整体代码评审周期的关键。获取位置根据合并请求中第一条非MR作者发布的评论或评审讨论串的时间戳推断。相关数据可通过系统备注或Notes API获取。采集查找MR中由非作者用户发布的第一条评论的时间戳。事件类型 inferred
	已添加批准	表示评审人员正式批准合并请求中的代码变更。当用户点击“Approve”按钮时，GitLab会捕获这一明确事件。
为什么重要批准是关键质量关卡。跟踪批准情况有助于分析获得必要签字确认所需的时间，并确保符合评审政策。获取位置从合并请求批准事件中获取。相关事件可通过Approvals API获取，也可在MR历史记录中查看。采集使用合并请求批准事件日志中的时间戳。事件类型 explicit
	开发已开始	该活动表示问题已开始进入实际编码阶段。由于GitLab没有明确的“start development”按钮，通常通过查找与问题关联的分支上首次推送的代码提交来推断。
为什么重要精准确定产生价值的开发工作的实际起点，从而准确衡量纯编码阶段，并将其与规划或排队时间区分开来。获取位置通过查找与问题关联的功能分支上的首次提交时间戳来推断。为此需要将问题与分支关联起来，通常通过命名约定或元数据实现。采集查找与问题ID关联的分支上的首次提交时间戳。事件类型 inferred
	流水线失败	当CI/CD流水线执行在任一阶段失败时，就会发生此活动，例如构建错误或测试失败。GitLab会明确记录每条流水线的最终状态，因此很容易识别失败。
为什么重要流水线失败是返工的主要原因之一。分析失败频率、持续时间和原因，有助于识别质量问题、不稳定测试，以及开发人员反馈闭环中的瓶颈。获取位置通过ci_pipelines表中流水线记录的“failed”状态识别。“finished_at”时间戳表示失败发生的时间。采集筛选状态为“failed”的流水线记录，并使用“finished_at”时间戳。事件类型 explicit
	流水线已开始	表示自动化CI/CD流水线启动，通常会执行构建、测试和安全扫描。每当流水线被触发时，例如提交代码或创建MR，GitLab都会明确创建带有开始时间戳的流水线记录。
为什么重要跟踪流水线执行情况对于监控自动化测试和集成流程的健康度与效率至关重要。这有助于识别自动化验证所耗费的时间。获取位置从ci_pipelines表中流水线记录的“created_at”或“started_at”时间戳，或通过Pipelines API获取。采集使用与MR分支关联的流水线执行记录中的时间戳。事件类型 explicit
	部署已开始	表示将代码发布到特定环境的流程开始，例如预发布环境或生产环境。在GitLab中，这对应于CI/CD流水线中“deploy”作业的启动。
为什么重要跟踪部署开始时间有助于单独衡量部署阶段的持续时间，对于测量和优化部署交付周期至关重要。获取位置从配置为部署作业的CI/CD作业的“started_at”时间戳获取。这属于GitLab的Environments和Deployments功能。采集使用部署任务对应CI作业日志中的“started_at”时间戳。事件类型 explicit
	问题已关闭	表示工作项最终完成管理上的关闭，通常发生在相关变更已部署并验证之后。当用户在GitLab中关闭问题时，系统会捕获这一明确事件。
为什么重要关闭问题通常表示所有相关工作最终结束。将其与部署时间进行比较，可以发现部署后验证或管理流程中的延迟。获取位置这是从issues表中的“closed_at”时间戳或对应系统备注中明确捕获的事件。采集使用问题的“closed_at”时间戳。事件类型 explicit
	问题已分配	表示将问题分配给特定开发人员或团队，说明工作责任人已经确定。当问题的assignee字段被填写或变更时，GitLab会记录这一明确事件。
为什么重要跟踪分配情况对于分析资源配置、团队工作负载和交接耗时至关重要。这有助于识别工作创建后到被接手之间的延迟。获取位置从问题的GitLab系统备注中获取。系统备注会记录assignee的添加或变更，事件时间戳也会记录在备注中。采集从问题的系统备注中提取“assignee changed”事件。事件类型 explicit

建议可选

提取指南

如何从GitLab获取数据

步骤

生成GitLab个人访问令牌：登录您的GitLab账户。进入“用户设置”>“访问令牌”。创建新令牌，至少授予read_api范围。请妥善保存令牌，因为它可以访问您的GitLab数据。
确定项目完整路径：进入您要分析的GitLab项目主页。完整路径显示在项目名称下方，通常格式为group/subgroup/project-name。
准备GraphQL查询环境：您可以使用任何能够发送POST请求的工具，例如Postman、Insomnia，或Python、Node.js等脚本语言。将请求URL设置为GitLab实例的GraphQL端点。对于GitLab.com，该端点为https://gitlab.com/api/graphql。
配置请求标头：为请求添加两个标头。将Content-Type设置为application/json，将Authorization设置为Bearer [Your Personal Access Token]，并将占位符替换为您生成的令牌。
设置查询变量：提供的GraphQL查询使用变量进行自定义。在请求正文中创建包含query和variables两个键的JSON对象。将提供的脚本粘贴到query值中，在variables值中将projectPath设置为项目完整路径，并定义createdAfter日期以指定提取窗口的起始时间。
执行查询：发送配置好的POST请求。GitLab API将返回包含所请求项目数据的嵌套JSON对象。
处理分页：对于开发项较多的项目，查询每页只返回有限数量的结果。响应包含pageInfo对象，其中有hasNextPage（布尔值）和endCursor（字符串）。要获取下一页，您必须重新运行查询，并将上一响应中的endCursor值作为issuesAfter变量传入。
将JSON转换为扁平事件日志：必须将嵌套JSON响应处理为表格格式。编写脚本遍历响应中的每个Issue。对每个Issue，提取其事件（创建、分配、关闭）以及关联Merge Requests的事件（创建、审批、流水线、合并、部署）。每个独立事件都应成为事件日志表中的一行。
映射活动和属性：处理JSON时，将数据映射到事件日志列。例如，issue.createdAt成为“Issue已创建”活动的StartTime。对于所有相关事件，issue.iid作为开发项案例ID。
导出为CSV：转换完成并获得所有事件的扁平列表后，将数据导出为CSV文件。确保列标题符合所需属性：DevelopmentItem、Activity、StartTime、EndTime、Assignee、DevelopmentItemType、Severity和ProjectName。
上传到ProcessMind：生成的CSV文件现在可以上传到ProcessMind进行分析。

配置

GraphQL端点：云端实例必须将查询发送到https://gitlab.com/api/graphql，自托管实例则发送到https://[your-gitlab-domain]/api/graphql。
身份验证：身份验证需要具有read_api范围的个人访问令牌。应将此令牌作为Bearer令牌放入Authorization标头。
项目路径：projectPath变量为必填项，用于指定数据提取目标项目。例如：'gitlab-org/gitlab'。
日期范围：使用createdAfter变量（格式为YYYY-MM-DDTHH:MM:SSZ）定义提取起点。建议提取3至6个月的数据，以获得有意义的分析结果，同时避免API负载过高。
分页控制：issuesFirst变量控制单次API调用返回的Issue数量。对于大型复杂项目，建议使用10或20等较小数值，以降低超时风险。您必须在脚本中实现分页循环，以获取全部数据。
标签约定：DevelopmentItemType和Severity的提取依赖项目中的标签用法。查询会查找Type::和Severity::等特定前缀的标签。您必须在后处理脚本中调整这些模式，以匹配团队的命名约定。

a 示例查询 graphql

query getProjectDevData(
  $projectPath: ID!,
  $createdAfter: Time,
  $issuesFirst: Int = 10,
  $issuesAfter: String
) {
  project(fullPath: $projectPath) {
    name
    issues(first: $issuesFirst, after: $issuesAfter, createdAfter: $createdAfter, state: all) {
      pageInfo {
        hasNextPage
        endCursor
      }
      nodes {
        iid
        createdAt
        closedAt
        author {
          username
        }
        assignees(first: 10) {
          nodes {
            username
          }
        }
        labels(first: 20) {
          nodes {
            title
          }
        }
        timelineEvents(first: 100) {
          nodes {
            ... on LabeledEvent {
              createdAt
              user {
                username
              }
            }
            ... on UnlabeledEvent {
              createdAt
              user {
                username
              }
            }
          }
        }
        relatedMergeRequests(first: 10) {
          nodes {
            iid
            createdAt
            author {
              username
            }
            assignees(first: 10) {
              nodes {
                username
              }
            }
            mergedAt
            approvedBy(first: 50) {
              nodes {
                username
                createdAt
              }
            }
            discussions(first: 50) {
              nodes {
                notes(first: 50) {
                  nodes {
                    author {
                      username
                    }
                    createdAt
                  }
                }
              }
            }
            commits(first: 1) {
              nodes {
                authoredDate
              }
            }
            pipelines(first: 20) {
              nodes {
                createdAt
                finishedAt
                status
                jobs(first: 100) {
                  nodes {
                    name
                    startedAt
                    finishedAt
                    status
                    environment {
                      name
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

步骤

建立数据库连接：获得自托管GitLab PostgreSQL数据库的只读访问权限。您需要主机、端口、数据库名称、用户名和密码。使用DBeaver、pgAdmin或命令行工具psql等标准SQL客户端进行连接。
确定目标项目：确定要分析的GitLab项目完整路径。路径格式应为“group/subgroup/project”。
自定义SQL查询：将提供的SQL查询复制到SQL客户端中，找到查询顶部的占位符部分。
设置分析参数：修改查询中的占位符。设置start_date和end_date以定义分析时间窗口，并将第2步确定的目标项目路径填入project_paths数组。
执行查询：针对GitLab数据库运行修改后的SQL查询。执行时间取决于GitLab实例规模和所选日期范围。
检查结果：查询将返回表格形式的事件日志，其中包含DevelopmentItem、Activity、StartTime等列。请快速检查结果，确认数据正确。
将数据导出为CSV：从SQL客户端将完整结果集导出为CSV文件。文件名应具有描述性，例如gitlab_event_log.csv。
准备上传CSV：确保导出的CSV文件符合以下上传要求：
- 文件采用UTF-8编码。
- 第一行包含查询生成的准确列标题（DevelopmentItem、Activity、StartTime等）。
- 时间戳采用ProcessMind可解析的格式，例如YYYY-MM-DD HH24:MI:SS。
上传到ProcessMind：将最终CSV文件上传到ProcessMind项目，开始分析。

配置

项目筛选：查询中的project_paths变量对于限定分析范围至关重要。您必须提供项目完整路径数组，例如ARRAY['group/project-a', 'group/project-b']。
日期范围：start_date和end_date变量控制提取时间窗口。建议先从3至6个月的周期开始，在分析价值和查询性能之间取得平衡。
数据库权限：需要拥有GitLab生产数据库或副本数据库只读权限的数据库用户。具体而言，该用户需要对issues、projects、merge_requests、notes、ci_pipelines、ci_builds、deployments和users等表拥有SELECT权限。
性能注意事项：直接查询大型且活跃的GitLab数据库可能消耗较多资源。强烈建议在业务低峰期执行提取，或使用只读副本数据库，以免影响生产环境性能。

a 示例查询 sql

WITH vars AS (
    SELECT
        '2023-01-01'::timestamp AS start_date,
        '2024-01-01'::timestamp AS end_date,
        ARRAY['your-group/your-project'] AS project_paths
),
issue_base AS (
    SELECT i.id, i.iid, i.project_id, i.author_id, i.assignee_id, i.created_at
    FROM issues i
    JOIN projects p ON i.project_id = p.id
    JOIN namespaces n ON p.namespace_id = n.id
    WHERE p.path_with_namespace = ANY((SELECT project_paths FROM vars))
    AND i.created_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)
)

-- 1. Issue Created
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Issue Created' AS "Activity",
    i.created_at AS "StartTime",
    i.created_at AS "EndTime",
    u_assignee.username AS "Assignee",
    l.name AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM issues i
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON i.project_id = p.id
LEFT JOIN users u_assignee ON i.assignee_id = u_assignee.id
LEFT JOIN label_links ll ON ll.target_id = i.id AND ll.target_type = 'Issue'
LEFT JOIN labels l ON l.id = ll.label_id AND l.name IN ('Feature', 'Bug', 'Task', 'Maintenance')

UNION ALL

-- 2. Issue Assigned
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Issue Assigned' AS "Activity",
    n.created_at AS "StartTime",
    n.created_at AS "EndTime",
    u_assignee.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM notes n
JOIN system_note_metadata snm ON n.id = snm.note_id
JOIN issues i ON n.noteable_id = i.id AND n.noteable_type = 'Issue'
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON i.project_id = p.id
LEFT JOIN users u_assignee ON i.assignee_id = u_assignee.id
WHERE snm.action = 'assignee'
AND n.created_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 3. Development Started (First commit on a related MR)
SELECT
    sub.DevelopmentItem,
    'Development Started' AS "Activity",
    sub.first_commit_date AS "StartTime",
    sub.first_commit_date AS "EndTime",
    sub.Assignee,
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    sub.ProjectName
FROM (
    SELECT 
        p.path_with_namespace || '!' || i.iid AS DevelopmentItem,
        c.committed_date as first_commit_date,
        u_assignee.username AS Assignee,
        p.name as ProjectName,
        ROW_NUMBER() OVER(PARTITION BY i.id ORDER BY c.committed_date ASC) as rn
    FROM merge_requests_closing_issues mrc
    JOIN merge_requests mr ON mrc.merge_request_id = mr.id
    JOIN issues i ON mrc.issue_id = i.id
    JOIN issue_base ib ON i.id = ib.id
    JOIN projects p ON i.project_id = p.id
    JOIN merge_request_diffs mrd ON mr.latest_merge_request_diff_id = mrd.id
    JOIN merge_request_diff_commits mrdc ON mrd.id = mrdc.merge_request_diff_id
    JOIN commits c ON mrdc.sha = c.sha
    LEFT JOIN users u_assignee ON mr.assignee_id = u_assignee.id
) sub
WHERE sub.rn = 1

UNION ALL

-- 4. Merge Request Created
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Merge Request Created' AS "Activity",
    mr.created_at AS "StartTime",
    mr.created_at AS "EndTime",
    u_assignee.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM merge_requests_closing_issues mrc
JOIN merge_requests mr ON mrc.merge_request_id = mr.id
JOIN issues i ON mrc.issue_id = i.id
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON mr.target_project_id = p.id
LEFT JOIN users u_assignee ON mr.assignee_id = u_assignee.id
WHERE mr.created_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 5. Pipeline Started
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Pipeline Started' AS "Activity",
    pipe.created_at AS "StartTime",
    pipe.finished_at AS "EndTime",
    u_assignee.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM ci_pipelines pipe
JOIN merge_requests mr ON pipe.merge_request_id = mr.id
JOIN merge_requests_closing_issues mrc ON mr.id = mrc.merge_request_id
JOIN issues i ON mrc.issue_id = i.id
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON mr.target_project_id = p.id
LEFT JOIN users u_assignee ON mr.assignee_id = u_assignee.id
WHERE pipe.created_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 6. Pipeline Failed
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Pipeline Failed' AS "Activity",
    pipe.finished_at AS "StartTime",
    pipe.finished_at AS "EndTime",
    u_assignee.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM ci_pipelines pipe
JOIN merge_requests mr ON pipe.merge_request_id = mr.id
JOIN merge_requests_closing_issues mrc ON mr.id = mrc.merge_request_id
JOIN issues i ON mrc.issue_id = i.id
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON mr.target_project_id = p.id
LEFT JOIN users u_assignee ON mr.assignee_id = u_assignee.id
WHERE pipe.status = 'failed'
AND pipe.finished_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 7. Code Review Started (First comment on MR by a non-author)
SELECT
    sub.DevelopmentItem,
    'Code Review Started' AS "Activity",
    sub.first_comment_time AS "StartTime",
    sub.first_comment_time AS "EndTime",
    sub.Assignee,
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    sub.ProjectName
FROM (
    SELECT 
        p.path_with_namespace || '!' || i.iid AS DevelopmentItem,
        n.created_at AS first_comment_time,
        u_assignee.username AS Assignee,
        p.name AS ProjectName,
        ROW_NUMBER() OVER(PARTITION BY mr.id ORDER BY n.created_at ASC) as rn
    FROM notes n
    JOIN merge_requests mr ON n.noteable_id = mr.id AND n.noteable_type = 'MergeRequest'
    JOIN merge_requests_closing_issues mrc ON mr.id = mrc.merge_request_id
    JOIN issues i ON mrc.issue_id = i.id
    JOIN issue_base ib ON i.id = ib.id
    JOIN projects p ON mr.target_project_id = p.id
    LEFT JOIN users u_assignee ON mr.assignee_id = u_assignee.id
    WHERE n.author_id != mr.author_id AND n.system = false
    AND n.created_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)
) sub
WHERE sub.rn = 1

UNION ALL

-- 8. Approval Added
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Approval Added' AS "Activity",
    a.created_at AS "StartTime",
    a.created_at AS "EndTime",
    u_assignee.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM approvals a
JOIN merge_requests mr ON a.merge_request_id = mr.id
JOIN merge_requests_closing_issues mrc ON mr.id = mrc.merge_request_id
JOIN issues i ON mrc.issue_id = i.id
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON mr.target_project_id = p.id
LEFT JOIN users u_assignee ON mr.assignee_id = u_assignee.id
WHERE a.created_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 9. Merge Request Merged
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Merge Request Merged' AS "Activity",
    mr.merged_at AS "StartTime",
    mr.merged_at AS "EndTime",
    u_merger.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM merge_requests_closing_issues mrc
JOIN merge_requests mr ON mrc.merge_request_id = mr.id
JOIN issues i ON mrc.issue_id = i.id
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON mr.target_project_id = p.id
LEFT JOIN users u_merger ON mr.merge_user_id = u_merger.id
WHERE mr.merged_at IS NOT NULL
AND mr.merged_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 10. Deployment Started
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Deployment Started' AS "Activity",
    d.created_at AS "StartTime",
    d.finished_at AS "EndTime",
    u_deployer.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM deployments d
JOIN projects p ON d.project_id = p.id
JOIN environments e ON d.environment_id = e.id
JOIN issues i ON d.deployable_id = i.id AND d.deployable_type = 'Issue'
JOIN issue_base ib ON i.id = ib.id
LEFT JOIN users u_deployer ON d.user_id = u_deployer.id
WHERE d.created_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 11. Deployed To Production
SELECT 
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Deployed To Production' AS "Activity",
    d.finished_at AS "StartTime",
    d.finished_at AS "EndTime",
    u_deployer.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM deployments d
JOIN projects p ON d.project_id = p.id
JOIN environments e ON d.environment_id = e.id
JOIN issues i ON d.deployable_id = i.id AND d.deployable_type = 'Issue'
JOIN issue_base ib ON i.id = ib.id
LEFT JOIN users u_deployer ON d.user_id = u_deployer.id
WHERE e.name = 'production' AND d.status = 2 -- success
AND d.finished_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars)

UNION ALL

-- 12. Issue Closed
SELECT
    p.path_with_namespace || '!' || i.iid AS "DevelopmentItem",
    'Issue Closed' AS "Activity",
    i.closed_at AS "StartTime",
    i.closed_at AS "EndTime",
    u_assignee.username AS "Assignee",
    NULL AS "DevelopmentItemType",
    NULL AS "Severity",
    p.name AS "ProjectName"
FROM issues i
JOIN issue_base ib ON i.id = ib.id
JOIN projects p ON i.project_id = p.id
LEFT JOIN users u_assignee ON i.assignee_id = u_assignee.id
WHERE i.closed_at IS NOT NULL
AND i.closed_at BETWEEN (SELECT start_date FROM vars) AND (SELECT end_date FROM vars);

步骤

前置条件：确保系统已安装Python 3.6或更高版本。使用pip安装所需的python-gitlab和pandas库。在终端或命令提示符中运行命令：pip install python-gitlab pandas。
生成GitLab访问令牌：登录您的GitLab实例，进入用户设置，然后打开“访问令牌”。创建新的个人访问令牌（PAT），填写易于识别的名称，并授予api和read_api范围。请妥善复制生成的令牌，因为之后将无法再次查看。
配置脚本：创建新的Python文件，例如extract_gitlab_log.py，并将提供的脚本代码复制到其中。编辑脚本顶部的配置部分。您必须填写GitLab实例URL、个人访问令牌、要分析的项目ID列表以及数据提取起始日期。
确定项目ID：要查找项目ID，请进入GitLab界面中的项目主页。项目ID通常直接显示在项目名称下方。
执行提取脚本：在终端中使用以下命令运行脚本：python extract_gitlab_log.py。脚本将连接GitLab API并开始获取数据。处理每个项目和Merge Request时，控制台会显示进度。
监控执行过程：根据项目数量和日期范围，脚本可能因所需API调用次数较多而运行较长时间。请关注控制台中的错误信息，例如身份验证失败或网络问题。
检查输出数据：脚本成功完成后，会在同一目录生成名为gitlab_event_log.csv的文件，其中包含原始事件日志。
转换和格式化数据：脚本会自动将时间戳格式化为ISO 8601标准（YYYY-MM-DDTHH:MM:SSZ）。对于离散事件，EndTime列与StartTime相同，这是流程挖掘事件日志中的常见做法。
准备上传：生成的CSV文件包含所需列：DevelopmentItem、Activity、StartTime以及其他建议属性，可直接上传到ProcessMind平台，通常无需进一步格式化。

配置

GitLab URL：GitLab实例的基础URL。例如，云端版本为https://gitlab.com，自托管实例则使用自定义URL。
个人访问令牌：身份验证需要有效的GitLab个人访问令牌，并授予api和read_api范围。该令牌所属用户至少应拥有目标项目的“Reporter”访问权限。
项目ID：要纳入提取范围的整数项目ID列表。将提取范围限定到具体项目，对于性能和数据相关性至关重要。
开始日期：采用ISO格式的日期字符串（例如2023-01-01T00:00:00Z），用于筛选此日期之后创建的Issue和Merge Request，从而限制提取数据量。建议先从最近3至6个月的数据开始，以控制数据规模。
生产环境名称：脚本包含占位变量PRODUCTION_JOB_NAME，应将其设置为向生产环境部署代码的CI/CD作业准确名称。这对于准确捕获“已开始部署到生产环境”活动至关重要。

a 示例查询 python

import gitlab
import pandas as pd
import os
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your GitLab instance URL, Private Access Token, and Project IDs
GITLAB_URL = os.environ.get(class="hl-string">'GITLAB_URL', class="hl-string">'[Your GitLab URL, e.g., https://gitlab.com]')
GITLAB_PRIVATE_TOKEN = os.environ.get(class="hl-string">'GITLAB_PRIVATE_TOKEN', class="hl-string">'[Your Personal Access Token]')
PROJECT_IDS = [12345, 67890]  class=class="hl-string">"hl-comment"># Replace with your target project IDs
SINCE_DATE = class="hl-string">'2023-01-01T00:00:00Z'  class=class="hl-string">"hl-comment"># Fetch data created after this date
PRODUCTION_JOB_NAME = class="hl-string">'deploy_production' class=class="hl-string">"hl-comment"># The exact name of your production deployment job

events = []

def add_event(case_id, activity, timestamp, end_timestamp=None, assignee=None, item_type=None, severity=None, project_name=None):
    class="hl-string">"""Helper function to add a new event to the list."""
    if timestamp:
        events.append({
            class="hl-string">'DevelopmentItem': case_id,
            class="hl-string">'Activity': activity,
            class="hl-string">'StartTime': pd.to_datetime(timestamp).isoformat() + class="hl-string">'Z',
            class="hl-string">'EndTime': pd.to_datetime(end_timestamp or timestamp).isoformat() + class="hl-string">'Z',
            class="hl-string">'Assignee': assignee,
            class="hl-string">'DevelopmentItemType': item_type,
            class="hl-string">'Severity': severity,
            class="hl-string">'ProjectName': project_name
        })

class=class="hl-string">"hl-comment"># Initialize GitLab API client
try:
    gl = gitlab.Gitlab(GITLAB_URL, private_token=GITLAB_PRIVATE_TOKEN)
    gl.auth()
    print(class="hl-string">"Successfully authenticated with GitLab.")
except Exception as e:
    print(fclass="hl-string">"Authentication failed: {e}")
    exit()

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
for project_id in PROJECT_IDS:
    try:
        project = gl.projects.get(project_id)
        print(fclass="hl-string">"\nProcessing project: {project.name_with_namespace}")

        class=class="hl-string">"hl-comment"># Process Issues first to establish the case ID
        issues = project.issues.list(all=True, created_after=SINCE_DATE)
        for issue in issues:
            print(fclass="hl-string">"  Processing Issue class="hl-commentclass="hl-string">">#{issue.iid}")
            case_id = fclass="hl-string">"{project.name_with_namespace}-I-{issue.iid}"
            assignee_name = issue.assignee[class="hl-string">'name'] if issue.assignee else None
            item_type = class="hl-string">'Bug' if class="hl-string">'bug' in [label.lower() for label in issue.labels] else class="hl-string">'Feature'

            class=class="hl-string">"hl-comment"># Activity: Issue Created
            add_event(case_id, class="hl-string">'Issue Created', issue.created_at, assignee=assignee_name, item_type=item_type, project_name=project.name)

            class=class="hl-string">"hl-comment"># Activity: Issue Assigned
            try:
                state_events = issue.resourcestateevents.list(all=True)
                for event in sorted(state_events, key=lambda x: x.created_at):
                    if event.action == class="hl-string">'add' and hasattr(event, class="hl-string">'user'):
                        add_event(case_id, class="hl-string">'Issue Assigned', event.created_at, assignee=event.user[class="hl-string">'name'], item_type=item_type, project_name=project.name)
                        break class=class="hl-string">"hl-comment"># Capture first assignment only
            except Exception as e:
                print(fclass="hl-string">"    Could not fetch state events for issue {issue.iid}: {e}")

            class=class="hl-string">"hl-comment"># Activity: Issue Closed
            if issue.closed_at:
                add_event(case_id, class="hl-string">'Issue Closed', issue.closed_at, assignee=assignee_name, item_type=item_type, project_name=project.name)

        class=class="hl-string">"hl-comment"># Process Merge Requests and link them to issues
        mrs = project.mergerequests.list(all=True, created_after=SINCE_DATE)
        for mr in mrs:
            print(fclass="hl-string">"  Processing MR !{mr.iid}")
            class=class="hl-string">"hl-comment"># Find the closing issue to use as the case_id
            closing_issues = mr.closes_issues()
            if not closing_issues:
                continue class=class="hl-string">"hl-comment"># Skip MRs not linked to an issue

            class=class="hl-string">"hl-comment"># Assuming one MR closes one issue for simplicity
            linked_issue_iid = closing_issues[0][class="hl-string">'iid']
            case_id = fclass="hl-string">"{project.name_with_namespace}-I-{linked_issue_iid}"
            assignee_name = mr.assignee[class="hl-string">'name'] if mr.assignee else None
            item_type = class="hl-string">'Bug' if class="hl-string">'bug' in [label.lower() for label in mr.labels] else class="hl-string">'Feature'

            class=class="hl-string">"hl-comment"># Activity: Merge Request Created
            add_event(case_id, class="hl-string">'Merge Request Created', mr.created_at, assignee=assignee_name, item_type=item_type, project_name=project.name)

            class=class="hl-string">"hl-comment"># Activity: Development Started (first commit)
            try:
                commits = mr.commits()
                if commits:
                    first_commit = commits[-1] class=class="hl-string">"hl-comment"># Commits are listed newest first
                    add_event(case_id, class="hl-string">'Development Started', first_commit.created_at, assignee=mr.author[class="hl-string">'name'], item_type=item_type, project_name=project.name)
            except Exception as e:
                print(fclass="hl-string">"    Could not fetch commits for MR {mr.iid}: {e}")

            class=class="hl-string">"hl-comment"># Activity: Code Review Started (first comment by non-author)
            try:
                notes = mr.notes.list(all=True, sort=class="hl-string">'asc')
                for note in notes:
                    if not note.system and note.author[class="hl-string">'id'] != mr.author[class="hl-string">'id']:
                        add_event(case_id, class="hl-string">'Code Review Started', note.created_at, assignee=note.author[class="hl-string">'name'], item_type=item_type, project_name=project.name)
                        break
            except Exception as e:
                print(fclass="hl-string">"    Could not fetch notes for MR {mr.iid}: {e}")

            class=class="hl-string">"hl-comment"># Activity: Approval Added
            try:
                approvals = mr.approvals.get()
                for approver in approvals.approved_by:
                    add_event(case_id, class="hl-string">'Approval Added', approver[class="hl-string">'approved_at'], assignee=approver[class="hl-string">'user'][class="hl-string">'name'], item_type=item_type, project_name=project.name)
            except Exception as e:
                print(fclass="hl-string">"    Could not fetch approvals for MR {mr.iid}: {e}")
            
            class=class="hl-string">"hl-comment"># Activity: Merge Request Merged
            if mr.merged_at:
                add_event(case_id, class="hl-string">'Merge Request Merged', mr.merged_at, assignee=mr.merged_by[class="hl-string">'name'], item_type=item_type, project_name=project.name)

            class=class="hl-string">"hl-comment"># Activities from Pipelines
            try:
                pipelines = mr.pipelines()
                for p in pipelines:
                    pipeline = project.pipelines.get(p[class="hl-string">'id'])
                    add_event(case_id, class="hl-string">'Pipeline Started', pipeline.created_at, assignee=pipeline.user[class="hl-string">'name'], item_type=item_type, project_name=project.name)
                    if pipeline.status == class="hl-string">'failed':
                        add_event(case_id, class="hl-string">'Pipeline Failed', pipeline.finished_at, assignee=pipeline.user[class="hl-string">'name'], item_type=item_type, project_name=project.name)
                    
                    class=class="hl-string">"hl-comment"># Activities from Jobs in the pipeline
                    jobs = pipeline.jobs.list(all=True)
                    for job in jobs:
                        if class="hl-string">'deploy' in job.name.lower() and job.started_at:
                            add_event(case_id, class="hl-string">'Deployment Started', job.started_at, assignee=job.user[class="hl-string">'name'], item_type=item_type, project_name=project.name)
                        if job.name == PRODUCTION_JOB_NAME and job.status == class="hl-string">'success' and job.finished_at:
                            add_event(case_id, class="hl-string">'Deployed To Production', job.finished_at, assignee=job.user[class="hl-string">'name'], item_type=item_type, project_name=project.name)
            except Exception as e:
                print(fclass="hl-string">"    Could not fetch pipelines/jobs for MR {mr.iid}: {e}")

    except gitlab.exceptions.GitlabError as e:
        print(fclass="hl-string">"Error processing project {project_id}: {e}")

class=class="hl-string">"hl-comment"># --- Create and Save DataFrame ---
if events:
    df = pd.DataFrame(events)
    df_sorted = df.sort_values(by=[class="hl-string">'DevelopmentItem', class="hl-string">'StartTime'], ascending=[True, True])
    df_sorted.to_csv(class="hl-string">'gitlab_event_log.csv', index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to gitlab_event_log.csv")
else:
    print(class="hl-string">"\nExtraction complete. No events found for the given projects and date range.")

步骤

准备监听服务：配置GitLab前，必须部署监听服务。这是一个具有公开URL、能够接收和处理HTTP POST请求的Web应用。该服务负责将GitLab事件负载转换为所需的事件日志格式。
开发转换逻辑：在监听服务中编写代码，解析GitLab传入的JSON负载。您需要将不同事件类型（object_kind）和操作映射到指定活动。例如，action: 'open'的issue事件应映射为“Issue已创建”活动。
进入GitLab Webhooks：登录您的GitLab实例，进入要监控的项目。在左侧导航栏中选择“设置”>“Webhooks”。
配置Webhook URL：在URL字段中输入第1步准备的监听服务端点完整公开URL。
设置密钥令牌：为确保安全，请生成一段较长的随机字符串作为密钥令牌，并填入相应字段。监听服务必须配置为从每个传入请求的X-Gitlab-Token标头验证该令牌，以确保请求来源可信。
选择触发事件：在“触发器”部分，选择捕获完整软件开发生命周期所需的全部事件类型。勾选“Push events”“Issues events”“Confidential issues events”“Merge request events”“Note events”“Job events”和“Pipeline events”。
添加Webhook：确保“启用SSL验证”复选框处于选中状态。点击“添加Webhook”保存配置。GitLab会立即向您的URL发送测试事件，以验证连接。
实现推断事件逻辑：部分活动不是GitLab中的直接事件，必须由监听服务推断。对于“开发已开始”，服务应检测与Issue关联的第一个“Push event”。对于“代码审查已开始”，服务应检测Merge Request上的第一个“Note event”（评论），且该评论由非作者用户创建。
处理部署事件：“部署已开始”和“已部署到生产环境”活动通过“Job events”捕获。您的服务需要解析这些事件，筛选名称为“deploy_staging”或“deploy_production”等特定作业，并检查其状态（“running”或“success”）。
存储事件日志数据：服务处理每个有效Webhook时，应立即将新行写入选定的数据存储，例如数据库或CSV文件。每行至少应包含DevelopmentItem（Issue或MR ID）、Activity和StartTime。
完成并导出：经过一段时间收集足够数据后，将数据存储中的事件日志导出为CSV文件。确保列标题符合ProcessMind要求，例如DevelopmentItem、Activity和StartTime。

配置

URL：用于接收Webhook负载的自定义监听服务端点。该URL必须稳定且可公开访问。
密钥令牌：监听服务用于验证传入请求合法且来自GitLab的安全密钥。这是关键的安全措施。
触发事件：将发送到端点的特定GitLab事件。要捕获完整生命周期，必须启用包括Issues、Push、Merge requests、Notes、Pipelines和Job events在内的完整事件集。
范围：Webhook可以在项目级别配置，用于监控单个代码仓库；也可以在群组级别配置，通过一次设置监控该群组中的所有项目。
监听服务逻辑：自定义应用逻辑是此方法中最关键的部分，负责解析不同结构的JSON负载，推断“开发已开始”等活动，并将事件数据映射为结构化事件日志格式。
前置条件：此方法要求您在GitLab项目或群组中拥有Maintainer或Owner权限，还需要单独开发的自定义Web服务作为监听端点。

a 示例查询 json

{
  "url": "https://[your-listening-service-url.com]/webhook-endpoint",
  "secret_token": "[your-secure-secret-token]",
  "merge_requests_events": true,
  "push_events": true,
  "issues_events": true,
  "note_events": true,
  "job_events": true,
  "pipeline_events": true,
  "wiki_page_events": false,
  "releases_events": false,
  "confidential_issues_events": true,
  "confidential_note_events": true,
  "enable_ssl_verification": true
}

准备开始了吗？

利用此模板准备数据，开始优化您的软件开发生命周期。立即着手改进流程！

返回改进指南下载模板

提升您的软件开发生命周期：立即开始优化

消除SDLC瓶颈，将周期时间缩短30%，提升质量。

开始免费试用

无需信用卡，立即开始优化。

您的软件开发生命周期数据模板

您的软件开发生命周期数据模板

软件开发生命周期属性

软件开发生命周期活动

提取指南

用于开发生命周期事件的GitLab GraphQL API

步骤

配置

a 示例查询 graphql

直接查询GitLab PostgreSQL数据库获取事件

步骤

配置

a 示例查询 sql

使用GitLab REST API客户端库的Python脚本

步骤

配置

a 示例查询 python

通过GitLab系统Webhook实时捕获事件

步骤

配置

a 示例查询 json

准备开始了吗？

提升您的软件开发生命周期：立即开始优化

您的软件开发生命周期数据模板

您的软件开发生命周期数据模板

软件开发生命周期属性

软件开发生命周期活动

提取指南

用于开发生命周期事件的GitLab GraphQL API

步骤

配置

a 示例查询 graphql

直接查询GitLab PostgreSQL数据库获取事件

步骤

配置

a 示例查询 sql

使用GitLab REST API客户端库的Python脚本

步骤

配置

a 示例查询 python

通过GitLab系统Webhook实时捕获事件

步骤

配置

a 示例查询 json

准备开始了吗？

提升您的软件开发生命周期：立即开始优化

我们重视您的隐私