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

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	发生的具体流程步骤或事件的名称，例如“创建问题”或“合并合并请求”。
说明活动属性记录开发事项经历的各项事件。这些事件并非以单一字段存储在GitLab中，而是根据Issues、Merge Requests和CI/CD Pipelines中的各种操作及时间戳字段整理得出。例如，创建问题、推送代码提交、流水线失败或批准合并请求，都是不同的活动。此属性是构建流程图、呈现工作流以及分析事件顺序和频率的基础。它可用于识别偏差、步骤间的瓶颈和常见流程路径。重要性此属性定义流程图中的步骤，用于呈现和分析端到端开发工作流。获取途径根据GitLab事件流中的事件类型和状态变化整理得出，也可通过解读Issues和Merge Requests中的“created_at”、“merged_at”和“closed_at”等时间戳字段获得。示例创建问题开始开发合并合并请求流水线失败部署到生产环境
	严重程度 Severity	开发事项的严重程度，通常用于缺陷或事件。
说明严重程度表示缺陷或问题的影响程度，从严重到轻微不等。GitLab没有内置的严重程度字段，因此几乎总是通过标签实现，例如“severity::1”、“severity::2”。此属性对于“严重程度升级趋势”仪表板及相关KPI至关重要。分析严重程度在整个生命周期中的变化，可以发现最初被低估的问题，或使问题恶化的流程。重要性有助于确定工作的优先级，并分析高严重程度事项是否得到更快处理。跟踪变化可支持“严重程度升级频率”KPI。获取途径根据GitLab问题上使用的“labels”整理得出。需要进行映射，以便将“S1”、“S2”等标签转换为严重程度级别。示例 1 - 严重2 - 高3 - 中4 - 低
	受分派人 Assignee	事件发生时被分派到问题或合并请求的用户。
说明受分派人是流程中某个时间点负责工作项的开发人员或用户。在GitLab中，此信息记录在问题或合并请求的`assignee`或`assignees`字段中。按受分派人分析对于“开发人员工作量与分配”仪表板至关重要。这有助于了解资源利用情况、识别工作负荷过重的个人或团队，以及分析不同人员之间的交接情况。重要性跟踪工作由谁完成，以便分析工作量、资源分配效率，并识别交接造成的延迟。获取途径从GitLab Issues和Merge Requests API响应中的“assignee.username”或“assignees”字段获取。示例 jdoeasmithr.williams
	开发事项类型 DevelopmentItemType	开发事项的分类，例如“功能”、“缺陷”、“任务”或“维护”。
说明此属性用于对正在执行的工作进行分类。在GitLab中，通常通过问题标签实现。团队使用标签区分新功能、缺陷修复、技术债务和其他工作类型。按开发事项类型分析，可以比较不同工作类型的流程路径和周期时间。例如，您可以分析缺陷是否比功能开发解决得更快，或技术债务任务是否遵循不同的审查流程。重要性按工作类型细分流程，有助于识别哪些工作更容易出现延迟、返工或偏差。获取途径通常根据GitLab问题上使用的“labels”整理得出。需要通过映射规则将具体标签转换为标准类型。示例功能缺陷任务技术债务
	结束时间 EndTime	表示活动或事件完成时间的时间戳。
说明 EndTime标记活动完成的准确日期和时间。对于GitLab中的许多原子事件，例如“创建问题”，EndTime与StartTime相同。对于有持续时间的活动，例如“代码审查”，EndTime表示活动完成的时间戳，例如给出最终批准的时间。此属性对于准确计算单项活动的持续时间（处理时间）至关重要。它有助于深入开展瓶颈分析，区分实际处理任务的时间与任务间的等待时间。重要性可用于精确计算活动持续时间（处理时间），这是识别流程低效步骤的关键。获取途径对于原子事件，此值与StartTime相同。对于有持续时间的活动，需要根据数据中对应的完成事件推导得出。示例 2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
	项目名称 ProjectName	开发事项所属GitLab项目的名称。
说明此属性用于标识开展工作的具体代码仓库或项目。在GitLab中，每个问题和合并请求都属于某个项目。按项目名称分析，可以比较不同产品、组件或服务的绩效，帮助识别哪些项目的SDLC流程更健康，也便于将仪表板筛选到您关注的特定领域。重要性支持按产品、应用或组件细分流程分析，以便有针对性地推动改进。获取途径从Project API中的“name”或“path_with_namespace”字段获取，并通过Issues和Merge Requests中的“project_id”关联。示例 platform/api-gatewayfrontend/customer-portalmobile/ios-app
	交接等待时间 HandoffWaitTime	由不同受分派人执行的两项连续活动之间的空闲时间。
说明此指标计算一项活动完成到下一项活动开始之间的间隔时长，尤其关注受分派人发生变化的情况。例如，它可以衡量开发人员完成工作到审查人员开始代码审查之间的时间。这是“平均交接等待时间”KPI的关键指标。它有助于发现资源分配和团队或个人间沟通中的隐性低效，揭示非工作时间造成的延迟。重要性量化不同人员或团队交接期间的空闲时间，揭示隐性延迟和沟通瓶颈。获取途径由流程挖掘工具计算。工具会分析案例中的连续事件，检查“受分派人”是否不同，并计算时间差。示例 1天2小时15分钟8小时
	发布版本 ReleaseVersion	与部署关联的计划版本或实际软件版本标签。
说明此属性标识开发项所属的具体软件版本。在GitLab中，版本信息可以通过里程碑、受保护的标签或Releases功能中的条目关联。此属性是“发布计划达成情况跟踪”仪表板的基础。将实际部署日期与发布版本对应的计划日期进行比较，组织便可衡量计划达成情况，并分析发布延迟的原因。重要性将开发项与具体软件版本关联，对于跟踪发布进度和计划达成情况至关重要。获取途径数据可取自GitLab Releases、git标签名称，或用于发布规划的里程碑标题。示例 v1.2.0v3.0.0-beta2023.4.1
	合并请求状态 MergeRequestStatus	事件关联的合并请求状态，例如“已打开”“已合并”或“已关闭”。
说明此属性记录事件发生时合并请求（MR）的状态。GitLab合并请求有几种状态：“opened”“closed”“merged”或“locked”。这与开发项的整体状态不同。跟踪合并请求状态对于分析软件开发生命周期（SDLC）中的代码集成阶段至关重要。它可用于“代码审查周期时间与吞吐量”等仪表板，帮助找出从创建MR到审查、批准和合并各环节的延迟。重要性展示代码审查和合并流程的情况，这通常是SDLC中的关键瓶颈。获取途径取自GitLab Merge Requests API响应中的“state”字段。示例待处理已合并已关闭已锁定
	周期时间 CycleTime	开发项从首次活动到最后一次活动所经过的总时间。
说明周期时间是一个计算指标，用于衡量单个案例的总时长。通常以单个开发项的首个事件（如“创建问题”）与最后一个事件（如“部署到生产环境”）之间的时间差计算。这是衡量整体流程效率的核心KPI，也是“SDLC端到端周期时间”等仪表板中的关键指标。它可用于跟踪改进情况，并找出可能反映系统性问题的长周期案例。重要性这是流程挖掘的核心KPI，用于衡量开发生命周期的端到端效率。获取途径流程挖掘工具按每个唯一CaseId计算，以最大StartTime减去最小StartTime得出。示例 10天4小时23小时15分钟35天
	团队名称 TeamName	与项目或受分派人关联的开发团队。
说明团队名称表示负责开发事项的团队或小组。GitLab通常没有标准字段记录此信息，往往需要根据项目命名约定、群组结构，或通过外部对照表将受分派人与所属团队关联起来。此属性用于分析团队层面的流程绩效，帮助比较不同团队的效率、工作量和流程遵循情况，并支持从团队视角查看“阶段瓶颈分析”等仪表板。重要性支持跨团队分析绩效和比较流程，帮助识别特定团队的瓶颈或最佳实践。获取途径通常通过将项目名称或受分派人映射到GitLab之外定义的团队结构来获取，也可根据GitLab群组层级推断。示例前端-Alpha后端-服务平台-基础设施
	开发事项状态 DevelopmentItemStatus	事件发生时开发事项的状态，例如“待处理”、“进行中”或“已关闭”。
说明此属性反映主要工作项的状态，通常是GitLab中的问题。GitLab问题有一个`state`字段，值可以是“opened”或“closed”。更细致的状态通常通过范围标签管理，例如“Status::Triage”、“Status::In-Dev”和“Status::In-Review”。跟踪状态变化对于了解案例生命周期至关重要。它有助于识别工作项在各状态停留的时间，也可用于筛选进行中或已完成的工作，例如查看“SDLC端到端周期时间”仪表板。重要性呈现案例当前状态，以便分析其在各阶段的耗时，并筛选进行中或已完成的工作。获取途径主要状态来自GitLab问题的“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	合并请求的目标分支名称。
说明目标分支是计划合入更改的分支，例如“main”“develop”或“release/1.5”等发布分支。这是合并请求的核心信息。按目标分支分析，可以发现代码合入不同目标时流程上的差异。例如，合入“main”的代码可能需要更严格的审批，周期时间也可能长于合入功能分支的代码。此属性还有助于区分生产部署与其他类型的代码集成。重要性有助于区分不同的开发和发布工作流，因为目标分支不同，流程也可能有显著差异。获取途径取自GitLab Merge Requests API响应中的“target_branch”字段。示例 maindeveloprelease/v2.1.0hotfix/user-auth-bug
	里程碑标题 MilestoneTitle	开发项所属里程碑或冲刺的标题。
说明 GitLab中的里程碑用于跟踪特定目标或时间段内的工作，例如一个冲刺或某个发布版本。此属性记录里程碑的名称或标题。借助此属性，您可以在特定冲刺或规划周期内分析流程表现，了解周期时间是否逐个冲刺缩短，也可以筛选流程视图，仅查看与即将发布的版本相关的工作。重要性将开发工作与冲刺或发布等规划周期关联起来，以便分析工作在计划时间段内的表现。获取途径取自GitLab Issues或Merge Requests API响应中的“milestone.title”字段。示例 2023年第四季度发布冲刺23.11阶段1：MVP

必填建议填写选填

软件开发生命周期活动

将这些关键流程步骤和里程碑记录到事件日志中，以便准确发现流程并识别瓶颈。

4 建议填写 8 选填

	活动	说明
	创建合并请求	表示初始开发工作已完成，代码已准备好进行审查和集成。这是GitLab工作流中的核心明确事件，在开发人员创建新的合并请求（MR）时捕获。
重要性这是一个关键里程碑，标志着工作从开发阶段交接到审查和测试阶段。它也是分析整个代码审查和CI/CD流水线周期的起点。获取途径这是一个明确记录的事件，可从“merge_requests”表中的“created_at”时间戳或Merge Requests API获取。采集使用合并请求的“created_at”时间戳。事件类型 explicit
	创建问题	此活动标志着开发生命周期的开始，表示创建了新的工作项，例如功能、缺陷或任务。用户在GitLab中创建问题时，系统会记录创建时间，因此可以明确捕获此事件。
重要性这是端到端流程的主要开始事件。分析从创建问题到部署的耗时，可以全面了解SDLC周期时间。获取途径这是一个明确记录的事件，可从“issues”表中的“created_at”时间戳或Issues 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中关闭问题时，系统会明确记录此事件。
重要性关闭问题通常表示所有相关工作已最终完成。将关闭时间与部署时间进行比较，可以发现部署后验证或管理流程中的延迟。获取途径这是一个明确记录的事件，可从“issues”表中的“closed_at”时间戳或相应的系统备注获取。采集使用问题的“closed_at”时间戳。事件类型 explicit
	分派问题	表示将问题分派给特定开发人员或团队，说明该工作已明确负责人。每当问题的受分派人字段被填写或更改时，GitLab都会记录此事件。
重要性跟踪分派情况对于分析资源分配、团队工作量和交接耗时至关重要。这有助于发现工作创建后到有人接手之间的延迟。获取途径从问题的GitLab系统备注中获取，这些备注会记录添加或更改“assignee”的时间。事件时间戳记录在备注中。采集从问题的系统备注中提取“assignee changed”事件。事件类型 explicit
	启动流水线	表示启动自动化CI/CD流水线，通常用于运行构建、测试和安全扫描。每当流水线被触发时，例如因代码提交或创建MR而触发，GitLab都会明确创建一条带有开始时间戳的流水线记录。
重要性跟踪流水线执行情况对于监控自动化测试和集成流程的健康状况与效率至关重要。这有助于了解自动验证耗时。获取途径从“ci_pipelines”表中流水线记录的“created_at”或“started_at”时间戳获取，也可通过Pipelines API获取。采集使用与MR分支关联的流水线执行记录中的时间戳。事件类型 explicit
	开始代码审查	标志着合并请求的同行审查开始。此事件根据首次与审查相关的操作推断，例如由非作者发布的第一条评论或讨论串。
重要性衡量从创建MR到开始审查的耗时，可以揭示排队延迟。缩短这段等待时间是减少整体代码审查周期的关键。获取途径根据合并请求中第一条非MR作者发布的评论或审查讨论串的时间戳推断。此数据可通过系统备注或Notes API获取。采集查找MR中由非作者发布的第一条用户评论的时间戳。事件类型 inferred
	开始开发	此活动表示开始对问题进行实际编码。通常根据与问题关联的分支上首次推送代码提交的时间推断，因为GitLab没有明确的“开始开发”按钮。
重要性准确定位创造价值的开发工作的起点，从而精确衡量纯编码阶段，并将其与规划或排队时间区分开来。获取途径通过查找与问题关联的功能分支上首次提交的时间戳来推断。此方法需要将问题与分支关联，通常通过命名约定或元数据实现。采集查找与问题ID关联的分支上的首次提交时间戳。事件类型 inferred
	开始部署	表示开始将代码发布到特定环境（如预发布或生产环境）。在GitLab中，这对应于CI/CD流水线中“deploy”作业的启动。
重要性跟踪部署开始时间有助于单独衡量部署阶段的耗时，对于衡量和优化部署周期至关重要。获取途径从配置为部署作业的CI/CD作业的“started_at”时间戳获取。这属于GitLab的Environments and Deployments功能。采集使用部署任务对应的CI作业日志中的“started_at”时间戳。事件类型 explicit
	流水线失败	CI/CD流水线执行的任何阶段失败时，都会发生此活动，例如构建错误或测试失败。GitLab会明确记录每条流水线的最终状态，因此很容易识别失败情况。
重要性流水线失败是导致返工的主要原因。分析失败的频率、持续时间和原因，有助于发现质量问题、不稳定的测试，以及开发人员反馈环节中的瓶颈。获取途径通过“ci_pipelines”表中流水线记录的“failed”状态识别。“finished_at”时间戳表示失败发生的时间。采集筛选状态为“failed”的流水线记录，并使用“finished_at”时间戳。事件类型 explicit
	添加批准	表示审查者正式批准合并请求中的代码更改。用户点击“Approve”按钮时，GitLab会明确记录此事件。
重要性批准是重要的质量关卡。跟踪批准情况有助于分析获得必要签字确认所需的时间，并确保遵循审查政策。获取途径从合并请求的批准事件中获取。可通过Approvals API获取，也可在MR历史记录中查看。采集使用合并请求批准事件日志中的时间戳。事件类型 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 [您的个人访问令牌]，并用您生成的令牌替换占位符。
设置查询变量：提供的GraphQL查询使用变量进行自定义。在请求正文中创建包含query和variables两个键的JSON对象。将提供的脚本粘贴到query值中；在variables值中，将projectPath设为项目完整路径，并设置createdAfter日期以指定提取时间范围的起点。
执行查询：发送配置好的POST请求。GitLab API将返回包含所请求项目数据的嵌套JSON对象。
处理分页：对于开发事项较多的项目，查询每页返回的结果数量有限。响应中包含pageInfo对象，其中有hasNextPage（布尔值）和endCursor（字符串）。要获取下一页，您必须重新运行查询，并将上次响应中的endCursor值作为issuesAfter变量传入。
将JSON转换为扁平事件日志：需要将嵌套JSON响应处理为表格格式。编写脚本遍历响应中的每个问题，提取其事件（创建、指派、关闭）以及关联合并请求的事件（创建、审批、流水线、合并、部署）。每个独立事件都应在事件日志表中占一行。
映射活动和属性：处理JSON时，将数据映射到事件日志列。例如，issue.createdAt对应“问题已创建”活动的StartTime。issue.iid作为所有相关事件的DevelopmentItem案例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调用返回的问题数量。对于大型复杂项目，设为10或20等较小数值可降低超时风险。您必须在脚本中实现分页循环，以获取全部数据。
标签约定：DevelopmentItemType和Severity的提取依赖项目中的标签。查询会查找带有Type::和Severity::等特定前缀的标签。您必须调整后处理脚本中的匹配模式，以符合团队的标签约定。

查询示例 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数据库可能会占用大量资源。强烈建议在非高峰时段执行提取，或使用只读副本数据库，以免影响生产环境性能。

查询示例 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并开始获取数据。处理各项目和合并请求时，进度会显示在控制台中。
监控运行情况：根据项目数量和日期范围，脚本可能需要较长时间运行，因为它需要发起大量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'。这有助于控制提取的数据量。建议从近期时间段开始，例如最近3到6个月，以确保数据量易于管理。
生产环境名称：脚本中包含占位变量PRODUCTION_JOB_NAME，应将其设为向生产环境部署代码的CI/CD作业准确名称。这对准确捕获“已部署到生产环境”活动至关重要。

查询示例 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）和操作映射到指定活动。例如，issue事件中action: 'open'对应“问题已创建”活动。
进入GitLab Webhook设置：登录您的GitLab实例并打开要监控的项目。在左侧导航栏中，进入“设置”>“Webhook”。
配置Webhook URL：在URL字段中，输入您在第一步准备的监听服务端点的完整公开访问地址。
设置密钥令牌：为确保安全，请创建一串较长的随机字符串作为密钥令牌，并填入相应字段。您必须将监听服务配置为验证每个传入请求X-Gitlab-Token标头中的令牌，以确认请求来源可信。
选择触发事件：在“触发”区域中，必须选择捕获完整软件开发生命周期所需的所有事件类型。勾选“推送事件”、“问题事件”、“机密问题事件”、“合并请求事件”、“备注事件”、“作业事件”和“流水线事件”。
添加Webhook：确保已启用“验证SSL”复选框。点击“添加Webhook”按钮保存配置。GitLab会立即向您的URL发送测试事件，以验证连接。
实现推断事件的逻辑：GitLab中有些活动并非直接事件，需要由监听服务推断。对于“开发已开始”，服务应检测与某个问题关联的首个“推送事件”。对于“代码审查已开始”，服务应检测由非作者用户在合并请求上创建的首个“备注事件”（评论）。
处理部署事件：“部署已开始”和“已部署到生产环境”活动通过“作业事件”捕获。服务需要解析这些事件，筛选名称符合特定条件的作业，例如deploy_staging或deploy_production，并检查其状态（running或success）。
存储事件日志数据：每当服务处理一个有效Webhook时，都应立即向您选择的数据存储（例如数据库或CSV文件）写入一行新记录。每行至少应包含DevelopmentItem（问题或MR ID）、Activity和StartTime。
完成并导出：收集足够的数据后，将数据存储中的事件日志导出为CSV文件。确保列标题符合ProcessMind的要求，例如DevelopmentItem、Activity和StartTime。

配置

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

查询示例 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

步骤

配置

查询示例 graphql

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

步骤

配置

查询示例 sql

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

步骤

配置

查询示例 python

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

步骤

配置

查询示例 json

准备好开始了吗？

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