> 持续流程改进 > 软件开发生命周期 (SDLC) > GitLab > 数据模板

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

GitLab

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

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

这份全面的模板将引导您了解分析软件开发生命周期流程所需的核心数据点。它概述了需要收集的关键属性、需要跟踪的主要活动，并为直接从 GitLab 提取这些信息提供了实用指南。有了这份资源，您可以充满信心地为深入的 Process Mining 准备 data。

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

不熟悉事件日志？了解如何创建流程挖掘事件日志.

下载模板

软件开发生命周期属性

这些是建议包含在事件日志中的 data 字段，用于全面的软件开发生命周期分析与优化。

3 必填 5 推荐 13 可选

	名称	描述
	开发项 DevelopmentItem	工作单元（如功能、Bug 修复或任务）的唯一标识符，用作主要的 case 标识符。
描述开发项代表在软件开发生命周期中流转的单个可跟踪工作单元。它将从创建到最终部署的所有相关活动连接成一个连贯的 case。在 GitLab 中，这通常由 Issue 的内部 ID (IID) 表示，该 ID 在项目内是唯一的。按开发项进行分析支持端到端交付周期的测量、瓶颈识别和流程一致性检查。它是理解从构思到生产的交付效率的基础。为何重要这是核心的 case 标识符，它将所有流程 event 关联在一起，从而能够追踪任何给定工作项的全生命周期。获取方式这通常是 GitLab Issue 的内部 ID (IID)。可以在 Issues API 响应的“iid”字段中找到。示例 1024512PRJ-2345
	开始时间 StartTime	指示某项活动或事件开始时间的时间戳。
描述 StartTime 标记特定活动发生的精确日期和时间。对于 GitLab 中的 event，这会在各种 timestamp 字段中捕获。例如，“Issue 已创建”活动的 StartTime 是该 issue 的 `created_at` timestamp，而“Merge Request 已合并”活动的 StartTime 则是该请求的 `merged_at` timestamp。此 timestamp 是 Process Mining 中的核心时间要素。它用于按时间顺序排列 event、计算活动之间的持续时间、测量交付周期以及分析流程随时间变化的绩效。为何重要该属性提供 event 的时间顺序，这对于计算所有基于时间的指标以及理解流程流转至关重要。获取方式从 GitLab 的各种 timestamp 字段中提取，如 Issue 上的 'created_at'、'updated_at'、'closed_at' 以及 Merge Request 上的 'merged_at'。示例 2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
	活动 Activity	发生的特定流程步骤或 event 的名称，例如“Issue 已创建”或“Merge Request 已合并”。
描述 Activity 属性捕获开发项上发生的各个 event。这些 event 不以单一字段形式存储在 GitLab 中，而是通过 Issue、Merge Request 和 CI/CD Pipeline 中的各种操作和 timestamp 字段推导得出。例如，创建 issue、推送 commit、pipeline 失败或批准 merge request 都是不同的活动。该属性是构建流程图、可视化 workflow 以及分析 event 顺序和频率的基础。它用于识别偏差、步骤间的瓶颈以及常见的流程路径。为何重要它定义了流程图中的步骤，支持端到端开发 workflow 的可视化和分析。获取方式源自 GitLab 事件流中的事件类型和状态变更，或通过解析 Issue 和 Merge Request 上的 'created_at'、'merged_at' 和 'closed_at' 等 timestamp 字段得出。示例问题已创建开发已开始Merge Request 已合并Pipeline 失败已部署到生产环境
	严重性 Severity	开发项的严重性级别，通常用于 bug 或事故。
描述严重性表示 bug 或 issue 的影响程度，从致命到轻微不等。GitLab 没有原生严重性字段，因此这几乎总是通过标签（例如“severity::1”、“severity::2”）来实现。该属性对于“严重性升级趋势”仪表板及相关 KPI 至关重要。分析生命周期中严重性的变化可以突出最初被低估的问题，或识别出加剧问题的流程。为何重要有助于确定工作的优先级，并分析高严重性项目是否得到更快处理。跟踪变更可支持“严重性升级频率”这一 KPI。获取方式源自应用在 GitLab Issue 上的“标签”。需要通过映射将“S1”、“S2”等标签解释为严重等级。示例 1 - 紧急2 - 高3 - 中4 - 低
	受理人 Assignee	event 发生时分配给 issue 或 merge request 的用户。
描述负责人是指在流程中特定时间点负责该工作项的开发人员或用户。在 GitLab 中，这在 Issue 或 Merge Request 的 `assignee` 或 `assignees` 字段中捕获。按负责人分析对于“开发人员工作量与分配”仪表板至关重要。它有助于了解资源利用率，识别过载的个人或团队，并分析不同人员之间的交接情况。为何重要追踪各项任务的执行者，以便进行工作负载分析、优化资源分配效率，并识别因交接导致的流程延迟。获取方式从 GitLab Issues 和 Merge Requests API 响应中的“assignee.username”或“assignees”字段中获取。示例 jdoeasmithr.williams
	开发项类型 DevelopmentItemType	开发项的分类，例如“功能”、“Bug”、“任务”或“维护”。
描述该属性对正在执行的工作性质进行分类。在 GitLab 中，这通常通过在 issue 上添加标签来实现。团队使用标签来区分新功能、缺陷修复、技术债和其他工作类型。按开发项类型进行分析可以比较不同类型工作的流程流转和交付周期。例如，分析人员可以分析 bug 修复是否比功能开发更快，或者技术债任务是否遵循不同的评审流程。为何重要按工作类型细分流程有助于识别某些类型的工作是否更容易出现延迟、返工或偏差。获取方式通常源自 GitLab Issue 中的“labels”。需要通过映射逻辑将特定的标签转换为标准化的类型。示例特性Bug任务技术债
	结束时间 EndTime	指示活动或事件完成的时间戳。
描述 EndTime 标记 Activity 完成的精确日期和时间。对于 GitLab 中的许多原子事件（如“Issue Created”），EndTime 与 StartTime 相同。对于有持续时间的 Activity（如“代码审查”），它代表完成时的 timestamp，例如给出最终审批的时间。此属性对于准确计算单个 Activity 的持续时间（处理时间）至关重要。通过区分在任务上投入的实际工作时间与任务之间的等待时间，它有助于进行详尽的瓶颈分析。为何重要支持计算精确的 Activity 持续时间（处理时间），这是识别流程中低效步骤的关键。获取方式对于原子 event，这与 StartTime 相同。对于具有持续时间的活动，必须通过在 data 中查找相应的完成 event 来推导。示例 2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
	项目名称 ProjectName	开发项所属的 GitLab 项目名称。
描述该属性标识正在进行工作的具体代码仓库或项目。在 GitLab 中，每个 issue 和 merge request 都包含在一个项目中。按项目名称进行分析可以比较不同产品、组件或服务的绩效。它可以帮助识别某些项目是否拥有比其他项目更健康的 SDLC 流程，并且对于将仪表板筛选到特定的关注区域非常有用。为何重要支持按产品、应用或组件进行流程分析切片，有助于开展针对性的改进工作。获取方式从 Project API 中的“name”或“path_with_namespace”字段中获取，通过 Issues 和 Merge Requests 中的“project_id”进行关联。示例 platform/api-gatewayfrontend/customer-portalmobile/ios-app
	Merge Request 状态 MergeRequestStatus	与该 event 关联的 Merge Request 状态，例如“已开启”、“已合并”或“已关闭”。
描述该属性捕获 event 发生时 Merge Request (MR) 的状态。GitLab MR 有不同的状态：“已开启”、“已关闭”、“已合并”或“已锁定”。这与整体开发项状态是分开的。跟踪 MR 状态对于分析 SDLC 的代码集成阶段至关重要。它直接支持“代码评审交付周期与吞吐量”等仪表板，并有助于精准发现 MR 创建、评审、批准和合并之间的延迟。为何重要提供对代码评审和合并过程的可见性，这通常是 SDLC 中的关键瓶颈。获取方式从 GitLab Merge Requests API 响应中的“state”字段中获取。示例 openedmerged已关闭locked
	Pipeline 状态 PipelineStatus	CI/CD pipeline 的运行状态，例如“成功”、“失败”或“运行中”。
描述该属性指示与 commit 或 merge request 关联的 CI/CD pipeline 执行结果。GitLab 中的常见状态包括“运行中”、“待处理”、“成功”、“失败”、“已取消”和“已跳过”。此 data 对于“返工与重运行分析”仪表板至关重要。频繁的 pipeline 失败可能是返工和延迟的主要来源，分析其频率、位置和影响是提高开发效率和代码质量的关键。为何重要追踪自动化构建和测试的成功与失败情况，帮助您识别返工循环以及代码质量或测试自动化中存在的问题。获取方式从 GitLab CI/CD Pipelines API 响应中的“status”字段中获取。示例成功失败运行中已取消
	交接等待时间 HandoffWaitTime	由不同负责人执行的两个连续 Activity 之间的计算空闲时间。
描述该指标计算一个活动结束与下一个活动开始之间的时间间隔，特别是在负责人发生变更的情况下。例如，它测量开发人员完成工作到评审员开始代码评审之间的时间。这是“平均交接等待时间”KPI 的关键指标。它有助于揭示资源分配以及团队或个人之间沟通中的隐藏低效问题，突出显示那些不属于任何实际工作部分的延迟。为何重要量化不同人员或团队之间交接时的闲置时间，揭示隐藏的延迟和沟通瓶颈。获取方式由 Process Mining 工具计算。它需要分析 case 内的连续 event，检查“Assignee”是否不同，然后计算时间差。示例 1 天 2 小时15 minutes8 小时
	最后数据更新 LastDataUpdate	时间戳，表示此事件的数据上次从源系统刷新的时间。
描述该属性记录 event data 最后一次从 Process Mining 数据集中提取或更新的日期和时间。它不代表 event 发生的时间，而是代表该 event 记录最后一次同步的时间。此信息对于理解 data 新鲜度和验证流程分析的时效性至关重要。它有助于用户确信仪表板和 KPI 是基于最新 data 的，并告知他们源系统与分析之间可能存在的滞后。为何重要提高 data 新鲜度的透明度，确保用户了解流程分析的实时性。获取方式此 timestamp 由 data 提取工具或 ETL 流程在 data 刷新时生成并记录。示例 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	发布版本 ReleaseVersion	与部署关联的计划或实际软件版本标签。
描述该属性标识开发项所属的具体软件版本。在 GitLab 中，这可以通过里程碑、受保护的标签或“发布 (Releases)”功能中的条目进行关联。这对于“发布计划准时率跟踪”仪表板至关重要。通过将实际部署日期与发布版本相关的计划日期进行对比，组织可以衡量其按时交付的能力，并诊断发布延迟的原因。为何重要将开发项连接到特定的软件发布版本，这对于跟踪发布进度和进度遵循情况至关重要。获取方式这可以源自 GitLab Releases、Git 标签名称或用于发布计划的里程碑标题。示例 v1.2.0v3.0.0-beta2023.4.1
	周期时间 CycleTime	开发项从第一个活动到最后一个活动所经过的总时间。
描述 Cycle Time 是一个衡量 case 总时长的计算指标。它通常计算单个开发项从第一个事件（例如“Issue Created”）到最后一个事件（例如“Deployed to Production”）之间的时间差。这是衡量整体流程效率的主要 KPI。它是“SDLC 端到端周期时间”等 dashboard 中的核心指标，用于跟踪改进情况并识别可能指示系统性问题的长时间运行 case。为何重要这是 Process Mining 的核心 KPI，用于衡量开发生命周期的端到端效率。获取方式由 Process Mining 工具针对每个唯一的 CaseId，用最大 StartTime 减去最小 StartTime 计算得出。示例 10天4小时23 小时 15 分钟35天
	团队名称 TeamName	与项目或负责人关联的开发团队。
描述团队名称代表负责开发项的小组或分队。此信息通常不是 GitLab 中的标准字段，往往通过项目命名规范、群组结构或使用外部参考表将负责人映射到其相应团队来得出。该属性用于在团队层面分析流程绩效。它有助于比较不同团队之间的效率、工作负载和流程遵循情况，为“特定阶段瓶颈分析”等仪表板提供团队维度的视角。为何重要支持跨不同团队的绩效分析和流程对比，有助于识别特定团队的瓶颈或最佳实践。获取方式通常通过将项目名称或负责人映射到 GitLab 外部定义的团队结构，或从 GitLab 群组层级推断得出。示例前端-Alpha后端服务平台基础设施
	处理时间 ProcessingTime	单个活动的持续时间，计算为结束时间与开始时间之差。
描述处理时间测量特定活动的实际工作时间，与活动之间的等待时间相区别。对于单个 event 记录，其计算方式为 EndTime 减去 StartTime。对于瞬时 event，处理时间为零。该指标对于“特定阶段瓶颈分析”至关重要。通过汇总某个阶段（如代码评审）内活动的处理时间，分析人员可以准确判断实际执行工作所花费的时间，从而帮助精准定位低效的流程步骤。为何重要测量单个活动的持续时间，有助于区分实际工作时间和闲置等待时间，从而进行精确的瓶颈分析。获取方式由 Process Mining 工具计算得出，为 Activity 的 EndTime 与 StartTime 之差。示例 2 hours 30 minutes0 分钟3 天 8 小时
	开发项状态 DevelopmentItemStatus	event 发生时开发项的状态，例如“开启”、“进行中”或“已关闭”。
描述该属性反映主要工作项的状态，在 GitLab 中通常是 Issue。GitLab Issue 有一个 `state`，可以是“opened”或“closed”。更细粒度的状态通常使用作用域标签管理（例如“Status::Triage”、“Status::In-Dev”、“Status::In-Review”）。跟踪状态变更对于理解 case 生命周期至关重要。它有助于识别项目在每种状态下花费的时间，并可用于在“SDLC 端到端交付周期”等仪表板中筛选进行中或已完成的工作。为何重要提供 case 状态的快照，支持分析各阶段耗时，并可筛选进行中与已完成的工作。获取方式主要状态来自 GitLab Issue 的“state”字段（“opened”、“closed”）。更细粒度的状态通常从标签推导得出。示例 opened已关闭进行中审核中
	是否返工 IsRework	一个布尔值标志，指示活动是否属于返工循环的一部分。
描述该计算属性标记代表流程倒退的活动，例如在测试开始后又返回开发阶段。此标记的逻辑通常涉及检测特定的活动序列，例如在同一个 case 中，“Pipeline 失败”或“QA 测试开始”之后发生了“开始开发”event。该属性直接支持“返工与重运行分析”仪表板和“测试后返工率”KPI。它允许对返工进行轻松筛选和量化，帮助团队了解其频率、原因以及对项目时间表的影响。为何重要直接标记并量化 rework，从而轻松分析流程低效和质量问题的起因及影响。获取方式由 Process Mining 工具通过分析每个 case 的 Activity 序列并识别指示 rework 的模式计算得出。示例 truefalse
	源系统 SourceSystem	标识 data 的来源系统。
描述该属性指定流程 data 的来源。对于此数据模型，其值将始终为“GitLab”。在可能合并来自多个系统（例如用于计划的 Jira 和用于执行的 GitLab）的流程 data 的环境中，包含此属性至关重要。它支持筛选、细分，并有助于维护数据血缘。为何重要确保数据来源清晰，这对于数据治理以及集成来自多个企业系统的数据至关重要。获取方式这是一个静态值“GitLab”，在 data 转换过程中添加。示例 GitLab
	目标分支 TargetBranch	Merge Request 的目标分支名称。
描述目标分支是变更打算合并入的分支，例如“main”、“develop”或类似“release/1.5”的发布分支。这是任何 Merge Request 的核心信息。按目标分支进行分析可以揭示针对不同合并目的地的不同流程行为。例如，合并到“main”分支可能比合并到功能分支具有更严格的审批流程和更长的交付周期。它还有助于将生产环境部署与其他类型的代码集成区分开。为何重要有助于区分不同的开发和发布 workflow，因为流程会根据目标分支的不同而显著变化。获取方式从 GitLab Merge Requests API 响应中的“target_branch”字段中获取。示例 maindeveloprelease/v2.1.0hotfix/user-auth-bug
	里程碑标题 MilestoneTitle	开发项所属的里程碑或 Sprint 的标题。
描述 GitLab 中的 Milestone 用于根据特定目标或时间框（如 sprint 或发布版本）跟踪工作。此属性用于捕获该 Milestone 的名称或标题。该属性允许在特定 sprint 或规划周期的背景下分析流程绩效。它可以用来查看周期时间是否从一个 sprint 到下一个 sprint 有所改善，或者过滤流程视图以仅显示与即将发布版本相关的工作。为何重要将开发工作与 Sprint 或发布等计划周期关联，从而分析实际表现与计划时间框的对比。获取方式从 GitLab Issues 或 Merge Requests API 响应中的“milestone.title”字段中获取。示例 2023年第四季度发布Sprint 23.11第一阶段：MVP

必填推荐可选

软件开发生命周期活动

这些是您事件日志中需要捕获的关键流程步骤和里程碑，以便准确进行流程发现和瓶颈识别。

4 推荐 8 可选

	活动	描述
	Merge Request 已创建	表示初始开发工作已完成，代码已准备好进行评审和集成。这是 GitLab workflow 中的一个明确核心 event，在开发人员创建新的 Merge Request (MR) 时捕获。
为何重要这是一个关键里程碑，标志着从开发到评审和测试的交接。它是分析整个代码评审和 CI/CD pipeline 周期的切入点。获取方式这是通过 Merge Requests API 或从“merge_requests”表中的“created_at” timestamp 捕获的明确 event。捕获使用 Merge Request 的 'created_at' 时间戳。事件类型 explicit
	Merge Request 已合并	此活动标志着代码评审和集成过程的成功完成。这是当用户将 Merge Request 的分支合并到目标分支时发生的一个明确 event。
为何重要这是一个重大里程碑，表明开发和评审已完成。它既是衡量开发周期的终点，也是衡量部署前置时间的起点。获取方式这是从“merge_requests”表中的“merged_at” timestamp 捕获的明确 event。合并时系统还会生成一条备注。捕获使用 Merge Request 的 'merged_at' 时间戳。事件类型 explicit
	已部署到生产环境	此活动标志着代码成功部署到线上生产环境并交付最终用户使用。当 GitLab CI/CD pipeline 中特定的“部署到生产环境”作业成功完成时，系统会捕获此活动。
为何重要这是流程的主要结束 event，标志着价值已交付。它对于测量总的端到端 SDLC 交付周期和发布频率至关重要。获取方式从专门指定的生产部署 CI/CD job 成功运行后的 'finished_at' timestamp 中捕获。GitLab 的 Environments 功能会明确跟踪此信息。捕获使用生产环境部署成功的 CI job 中的 'finished_at' 时间戳。事件类型 explicit
	问题已创建	此活动标志着开发生命周期的开始，代表创建了一个新的工作项（如功能、bug 或任务）。当用户在 GitLab 中创建新 issue 时，系统会显式捕获该操作并记录创建 timestamp。
为何重要这是端到端流程的主要起始 event。分析从 issue 创建到部署的时间，可以完整展现 SDLC 交付周期。获取方式这是通过 Issues API 或从“issues”表中的“created_at” timestamp 捕获的明确 event。系统备注也会记录此创建 event。捕获使用 Issue 的 'created_at' 时间戳。事件类型 explicit
	Pipeline 失败	此活动发生在 CI/CD pipeline 执行在任何阶段失败时，例如构建错误或测试失败。GitLab 会显式记录每个 pipeline 的最终状态，使得故障易于识别。
为何重要 Pipeline 失败是导致返工的主要原因。分析其频率、持续时间和原因有助于识别质量问题、不稳定的测试以及向开发人员反馈循环中的瓶颈。获取方式通过“ci_pipelines”表中的 pipeline 记录状态为“failed”来识别。“finished_at” timestamp 指示故障发生的时间。捕获筛选状态为“failed”的 pipeline 记录，并使用“finished_at” timestamp。事件类型 explicit
	Pipeline 已开始	代表自动 CI/CD pipeline 的启动，通常运行构建、测试和安全扫描。每当 pipeline 被触发（例如通过 commit 或 MR 创建）时，GitLab 都会显式创建一个带有开始 timestamp 的 pipeline 记录。
为何重要跟踪 pipeline 执行情况对于监控自动化测试和集成过程的健康度与效率至关重要。它有助于识别在自动化验证上花费了多少时间。获取方式从 'ci_pipelines' 表中的流水线记录或通过 Pipelines API 获取 'created_at' 或 'started_at' timestamp。捕获使用与 MR 分支关联的 Pipeline 执行记录中的时间戳。事件类型 explicit
	代码审查已开始	标记 Merge Request 同行评审流程的开始。该 event 是根据首个评审相关操作推断的，例如作者以外的人员发布的第一个评论或线程。
为何重要测量从 MR 创建到开始评审的时间可以突出排队延迟。减少这段等待时间是缩短整个代码评审周期的关键。获取方式根据 Merge Request 上非作者的首条评论或评审线程的 timestamp 推断。此 data 可通过系统备注或 Notes API 获取。捕获在 MR 中查找非作者用户的首次评论 timestamp。事件类型 inferred
	已添加审批	代表评审员对 Merge Request 中的代码变更进行了正式批准。这是 GitLab 在用户点击“批准”按钮时捕获的一个明确 event。
为何重要审批是关键的质量关卡。通过跟踪审批，有助于分析获取必要签字所需的时间，并确保符合审查政策。获取方式从 Merge Request 审批事件中捕获。这些信息可以通过 Approvals API 获取，或在 MR 历史记录中查看。捕获使用 Merge Request 审批事件日志中的时间戳。事件类型 explicit
	开发已开始	此活动标志着针对该 issue 的实际编码工作的开始。由于 GitLab 没有显式的“开始开发”按钮，这通常根据推送到与该 issue 关联分支的首个代码 commit 来推断。
为何重要精准定位增值开发工作的确切起点，从而准确测量纯编码阶段，并将其与计划或排队时间区分开。获取方式通过查找与该 issue 链接的功能分支上的首个 commit timestamp 来推断。这需要将 issue 与分支关联，通常通过命名规范或元数据实现。捕获在与 issue ID 关联的分支上查找首次 commit 的 timestamp。事件类型 inferred
	部署已开始	代表开始将代码发布到特定环境（如预发布或生产环境）的过程。在 GitLab 中，这对应于 CI/CD pipeline 中“部署”作业的开始。
为何重要跟踪部署的开始有助于分离部署阶段的持续时间。这对于测量和优化部署前置时间至关重要。获取方式从配置为部署 job 的 CI/CD job 的 'started_at' timestamp 中捕获。这是 GitLab Environments 和 Deployments 功能的一部分。捕获使用部署任务 CI job 日志中的 'started_at' 时间戳。事件类型 explicit
	问题已关闭	代表工作项的最终管理性关闭，通常在变更已部署并验证之后。这是在用户于 GitLab 中关闭 issue 时捕获的明确 event。
为何重要关闭 Issue 通常意味着所有相关工作的最终结束。将其与部署时间进行对比，可以揭示部署后验证或行政流程中的延迟。获取方式这是从“issues”表中的“closed_at” timestamp 或相应的系统备注中捕获的明确 event。捕获使用 Issue 的 'closed_at' 时间戳。事件类型 explicit
	问题已分配	代表将 issue 分配给特定的开发人员或团队，表示已确立工作的归属。每当 issue 的负责人字段被填写或更改时，GitLab 都会记录这一明确 event。
为何重要跟踪指派情况对于分析资源分配、团队工作量和交接时间至关重要。它有助于识别从工作创建到被接手之间的延迟。获取方式从 GitLab Issue 的系统备注中捕获，该备注记录了添加或更改“负责人”的时间。事件的 timestamp 记录在备注中。捕获从 Issue 的系统备注中提取“负责人变更”事件。事件类型 explicit

推荐可选

提取指南

如何从 GitLab 获取您的 data

步骤

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

配置

GraphQL Endpoint: 对于云端实例，查询必须发送到 https://gitlab.com/api/graphql；对于私有化部署实例，则发送到 https://[your-gitlab-domain]/api/graphql。
身份验证: 身份验证需要具备 read_api 权限的个人访问令牌。该令牌应作为 Bearer 令牌包含在 Authorization 请求头中。
Project Path: projectPath 变量是必填项，用于指定要提取 data 的目标项目。例如：'gitlab-org/gitlab'。
日期范围: 使用 createdAfter 变量（格式为 YYYY-MM-DDTHH:MM:SSZ）来定义提取的起始点。建议提取 3 到 6 个月的 data，以便在不给 API 造成过大负担的情况下进行有意义的分析。
分页控制: issuesFirst 变量控制单个 API 调用中返回的 Issue 数量。对于大型复杂项目，设置较小的数字（如 10 或 20）可以降低超时风险。您必须在脚本中实现分页循环以检索所有 data。
标签规范: 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 等标准 SQL 客户端或命令行工具 psql 进行连接。
确定目标项目: 确定您要分析的 GitLab 项目的完整路径。路径格式应为 'group/subgroup/project'。
自定义 SQL 查询: 将提供的 SQL 查询语句复制到您的 SQL 客户端。找到查询语句顶部的占位符部分。
设置分析参数: 修改查询中的占位符。设置 start_date 和 end_date 以定义分析的时间窗口。在 project_paths 数组中填入第 2 步中确定的目标项目路径。
执行查询: 对 GitLab 数据库运行修改后的 SQL 查询。执行时间将取决于您的 GitLab 实例大小和所选的日期范围。
检查结果: 查询将返回一个表格形式的 event log，包含 DevelopmentItem、Activity、StartTime 等列。简要检查结果以确保其准确性。
导出 data 为 CSV: 将 SQL 客户端中的完整结果集导出为 CSV 文件。为文件起一个描述性的名称，例如 gitlab_event_log.csv。
准备 upload 的 CSV: 确保导出的 CSV 文件符合以下 upload 标准：
- 文件采用 UTF-8 编码。
- 第一行包含查询生成的准确标题名称（DevelopmentItem、Activity、StartTime 等）。
- timestamp 格式可供 ProcessMind 解析，例如 YYYY-MM-DD HH24:MI:SS。
upload 至 ProcessMind: 将最终的 CSV 文件 upload 到您的 ProcessMind 项目中开始分析。

配置

项目过滤器: 查询中的 project_paths 变量对于界定分析范围至关重要。您必须提供完整项目路径的数组，例如：ARRAY['group/project-a', 'group/project-b']。
日期范围: start_date 和 end_date 变量控制提取的时间窗口。建议从 3 到 6 个月的时间段开始，以确保在有价值的 data 与查询性能之间取得平衡。
数据库权限: 需要一个对 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 实例。导航至用户设置，然后进入“Access Tokens”。创建一个新的个人访问令牌 (PAT)。为其指定一个描述性名称，并授予 api 和 read_api 权限。安全地复制生成的令牌，因为您将无法再次查看它。
配置脚本: 创建一个新的 Python 文件（例如 extract_gitlab_log.py），并将提供的脚本代码复制到其中。编辑脚本顶部的配置部分。您必须提供 GitLab 实例 URL、私有访问令牌、要分析的项目 ID 列表以及 data 提取的开始日期。
获取项目 ID: 要查找项目 ID，请在 GitLab UI 中导航至项目主页。项目 ID 通常直接显示在项目名称下方。
执行提取脚本: 在终端中使用命令 python extract_gitlab_log.py 运行脚本。脚本将连接到 GitLab API 并开始获取 data。在处理每个项目和 Merge Request 时，您会在控制台中看到打印出的进度。
监控执行过程: 取决于项目数量和日期范围，由于需要进行大量的 API 调用，脚本可能需要较长时间运行。请监控控制台是否有错误信息，例如身份验证失败或网络问题。
检查输出数据: 脚本成功运行后，将在同一目录下生成名为 gitlab_event_log.csv 的文件。该文件包含原始的 event log。
Data 转换与格式化: 脚本会自动将 timestamp 格式化为 ISO 8601 标准 (YYYY-MM-DDTHH:MM:SSZ)。对于离散事件，EndTime 列被设置为与 StartTime 相同，这是 Process Mining event log 的常见做法。
准备 upload: 生成的 CSV 文件结构包含所需的列：DevelopmentItem、Activity、StartTime 以及其他推荐属性。该文件已准备好 upload 到 ProcessMind 平台，通常无需进一步格式化。

配置

GitLab URL: 您的 GitLab 实例的基础 URL，例如云端版本的 https://gitlab.com 或私有化部署实例的自定义 URL。
Personal Access Token: 用于身份验证的有效 GitLab 个人访问令牌，需要具备 api 和 read_api 权限。该令牌应属于对目标项目至少拥有“Reporter”访问权限的用户。
Project IDs: 您希望包含在提取范围内的项目 ID 的 Python 整数列表。将提取范围限定在特定项目对于提升性能和数据相关性至关重要。
Start Date: ISO 格式的日期字符串（例如 '2023-01-01T00:00:00Z'），用于过滤在此日期之后创建的 Issue 和 Merge Request。这有助于限制提取的 data 量。我们建议从最近的时间段（如过去 3 到 6 个月）开始，以确保 data 量可控。
Production Environment Name: 脚本包含一个占位符变量 PRODUCTION_JOB_NAME，应将其设置为向生产环境部署代码的 CI/CD job 的确切名称。这对于准确捕获“部署到生产环境”这一 Activity 至关重要。

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 的 Web 应用程序，能够接收并处理 HTTP POST 请求。该服务将包含将 GitLab event payload 转换为所需 event log 格式的逻辑。
开发转换逻辑: 在您的监听服务中编写代码，解析来自 GitLab 的 JSON payload。您需要将不同的事件类型 (object_kind) 和动作映射到指定的 Activity。例如，action: 'open' 的 issue 事件对应“Issue Created” Activity。
导航至 GitLab Webhooks: 登录您的 GitLab 实例，导航至您要监控的项目。在左侧导航栏中，转到 Settings > Webhooks。
配置 Webhook URL: 在 URL 字段中，输入您在第一步中准备的监听服务 endpoint 的完整、公开可访问的 URL。
设置 Secret Token: 出于安全考虑，创建一个随机的长字符串作为 Secret Token。在对应字段中输入此令牌。您的监听服务必须配置为验证每个请求头 X-Gitlab-Token 中的令牌，以确保真实性。
选择触发事件: 在“Trigger”部分，您必须选择捕获完整软件开发生命周期所需的所有事件类型。勾选“Push events”、“Issues events”、“Confidential issues events”、“Merge request events”、“Note events”、“Job events”和“Pipeline events”。
添加 Webhook: 确保勾选了“Enable SSL verification”。点击“Add webhook”按钮保存配置。GitLab 会立即向您的 URL 发送一个测试事件以验证连通性。
实现推断事件逻辑: 某些 Activity 在 GitLab 中并不是直接事件，必须由您的监听服务进行推断。对于“Development Started”，您的服务应检测与 Issue 关联的第一个“Push event”。对于“Code Review Started”，它应检测非作者用户在 Merge Request 上发表的第一个“Note event”（评论）。
处理部署事件: “Deployment Started”和“Deployed To Production” Activity 通过“Job events”捕获。您的服务需要解析这些事件，过滤特定名称的 job（如 'deploy_staging' 或 'deploy_production'），并检查其状态（'running' 或 'success'）。
存储 event log 数据: 当您的服务处理每个有效的 webhook 时，应立即在您选择的 data store（如数据库或 CSV 文件）中写入新行。每行必须至少包含 DevelopmentItem（Issue 或 MR ID）、Activity 和 StartTime。
定稿并导出: 在收集了足够的 data 后，将 event log 从 data store 导出为 CSV 文件。确保列标题符合 ProcessMind 的要求，例如 DevelopmentItem、Activity 和 StartTime。

配置

URL: 您的自定义监听服务的 endpoint，用于接收 webhook payload。该 URL 必须稳定且可公开访问。
Secret Token: 您的监听服务用于验证请求合法性并确认其源自 GitLab 的安全密钥。这是一项关键的安全措施。
触发事件: 将发送到您的 endpoint 的特定 GitLab event。为了捕获完整的生命周期，您必须启用完整的事件集，包括 Issues、Push、Merge requests、Notes、Pipelines 和 Job event。
Scope: Webhook 可以在项目级别为单个代码库配置，也可以在群组级别配置，以便通过单一配置监控该群组内的所有项目。
监听服务逻辑: 自定义应用程序逻辑是此方法中最核心的部分。它负责解析不同的 JSON payload，推断诸如“开发已开始”之类的 Activity，并将 event data 映射到结构化的 event log 格式。
前提条件: 此方法需要具有 GitLab 项目或群组的 Maintainer 或 Owner 权限。此外，还需要一个单独的、自定义开发的 Web 服务作为监听 endpoint。

a 查询示例 config

{
  "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
}

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

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

软件开发生命周期属性

软件开发生命周期活动

提取指南

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

步骤

配置

a 查询示例 graphql

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

步骤

配置

a 查询示例 sql

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

步骤

配置

a 查询示例 python

通过 GitLab 系统 Webhook 实时捕获 Event

步骤

配置

a 查询示例 config

准备好开始了吗？

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

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

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

软件开发生命周期属性

软件开发生命周期活动

提取指南

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

步骤

配置

a 查询示例 graphql

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

步骤

配置

a 查询示例 sql

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

步骤

配置

a 查询示例 python

通过 GitLab 系统 Webhook 实时捕获 Event

步骤

配置

a 查询示例 config

我们重视您的隐私

准备好开始了吗？

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