ソフトウェア開発ライフサイクルデータ``テンプレート

GitLab
ソフトウェア開発ライフサイクル`データ``テンプレート`

ソフトウェア開発ライフサイクルデータ``テンプレート

この包括的な`テンプレート`は、ソフトウェア開発ライフサイクル`プロセス`を分析するために必要な重要な`データポイント`をご案内します。収集すべき重要な`属性`、追跡すべき主要な`アクティビティ`を概説し、`GitLab`からこの情報を直接抽出するための実用的なガイダンスを提供します。このリソースを活用することで、洞察力に富む`プロセスマイニング`のために自信を持って`データ`を準備できます。
  • 収集を推奨する項目
  • 追跡すべき主要アクティビティ
  • 抽出の手引き
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

ソフトウェア開発ライフサイクル属性

これらは、包括的なソフトウェア開発ライフサイクル分析と最適化のために、`イベントログ`に含めることを推奨される`データフィールド`です。
3 必須 5 推奨 13 任意
名前 説明
アクティビティ
Activity
発生した特定の`プロセスステップ`または`イベント`の名前。例えば、「`課題`作成」や「`マージリクエスト`マージ済み」など。
説明

アクティビティ属性は、開発アイテムに発生する個別のイベントを捕捉します。これらはGitLabで単一フィールドとして格納されるのではなく、課題マージリクエストCI/CDパイプラインにわたる様々なアクションtimestamp``フィールドから導出されます。例えば、課題の作成、コミットのプッシュ、パイプラインの失敗、マージリクエストの承認はすべて個別のアクティビティです。

この属性は、プロセスマップの構築、ワークフローの可視化、イベントシーケンスと頻度の分析に不可欠です。逸脱、ステップ間のボトルネック、一般的なプロセスパスを特定するために使用されます。

その重要性

プロセスマップ内のステップを定義し、エンドツーエンドの開発ワークフローの可視化と分析を可能にします。

取得元

GitLabのイベントストリーム内のイベントタイプと状態変更から導出されるか、またはIssueおよびマージリクエストの「created_at」、「merged_at」、「closed_at」などのタイムスタンプフィールドを解釈することによって導出されます。

問題作成開発開始マージリクエストマージ済み`パイプライン`失敗本番環境にデプロイ済み
開始時刻
StartTime
アクティビティまたはイベントの開始時点を示すタイムスタンプ。
説明

StartTimeは、特定のアクティビティが発生した正確な日付と時刻を示します。GitLabにおけるイベントの場合、これは様々なtimestamp``フィールドで捕捉されます。例えば、「課題作成」アクティビティStartTime課題created_at timestampとなり、「マージリクエストマージ済み」アクティビティStartTimeマージリクエストmerged_at timestampとなります。

このtimestampプロセスマイニングにおける中心的な時間要素です。イベントを時系列にソートしたり、アクティビティ間の期間を計算したり、サイクルタイムを測定したり、プロセスパフォーマンス経時的に分析したりするために使用されます。

その重要性

この属性は、イベントの時系列シーケンスを提供します。これは、すべての時間ベース``メトリックを計算し、プロセスフローを理解するために不可欠です。

取得元

GitLabの様々なタイムスタンプフィールドから抽出されます。例えば、Issueの「created_at」、「updated_at」、「closed_at」、およびマージリクエストの「merged_at」などです。

2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
開発項目
DevelopmentItem
機能、`バグ`修正、`タスク`など、`作業`単位の一意の`識別子`であり、主要な`ケース識別子`として機能します。
説明

開発アイテムは、ソフトウェア開発ライフサイクルを経由する単一の追跡可能な作業を表します。それは作成から最終デプロイメントまで、すべての関連アクティビティを一貫したケースに接続します。GitLabでは、これは通常、プロジェクト内で一意な課題の内部IDIID)によって表現されます。

開発アイテムによる分析は、エンドツーエンドのサイクルタイム測定、ボトルネック特定、およびプロセス適合性チェックを可能にします。これは、コンセプトから本番環境まで、作業がいかに効率的に提供されるかを理解するための基盤を形成します。

その重要性

これは、すべてのプロセスイベントリンクする不可欠なケース識別子であり、特定の作業アイテムの完全なライフサイクルを追跡することを可能にします。

取得元

これは通常、GitLab課題の内部IDIID)です。Issues APIレスポンスの「iid」フィールドで見つけることができます。

1024512PRJ-2345
`プロジェクト名`
ProjectName
開発`アイテム`が属する`GitLab``プロジェクト`の名前。
説明

この属性は、作業が行われている特定のコードリポジトリまたはプロジェクトを識別します。GitLabでは、すべての課題マージリクエストプロジェクト内に含まれています。

プロジェクト名による分析は、異なる製品、コンポーネント、またはサービス間でパフォーマンスを比較することを可能にします。特定のプロジェクトが他のプロジェクトよりも健全なSDLCプロセスを持っているかどうかを特定するのに役立ち、特定の関心領域にダッシュボードフィルタリングするのに有用です。

その重要性

製品、アプリケーション、またはコンポーネント別にプロセス分析をセグメント化でき、対象を絞った改善活動を促進します。

取得元

プロジェクトAPIの「name」または「path_with_namespace」フィールドから取得され、課題およびマージリクエストの「project_id」を介してリンクされます。

platform/api-gatewayfrontend/customer-portalmobile/ios-app
Assignee
Assignee
`イベント`発生時に`課題`または`マージリクエスト`に割り当てられたユーザー。
説明

アサイニーは、プロセスの特定の時点で作業アイテムを担当する個々の開発者またはユーザーです。GitLabでは、これは課題またはマージリクエストassigneeまたはassignees フィールドに捕捉されます。

アサイニーによる分析は、「開発者ワークロード配分ダッシュボードにとって不可欠です。これは、リソース利用率を理解し、過負荷の個人やチームを特定し、異なる人々の間の引き継ぎを分析するのに役立ちます。

その重要性

誰が作業を行ったかを追跡し、ワークロード分析、リソース割り当ての効率化、および引き継ぎによる遅延の特定を可能にします。

取得元

GitLab課題およびマージリクエストAPI``レスポンスの「assignee.username」または「assignees」フィールドから取得されます。

jdoeasmithr.williams
終了日時
EndTime
アクティビティまたはイベントが完了した時点を示すタイムスタンプ。
説明

EndTimeは、アクティビティが終了した正確な日時を示します。GitLabの多くの原子的なイベント、例えば「Issue Created」では、EndTimeはStartTimeと同じです。期間を持つアクティビティ、例えば「Code Review」では、最終承認が与えられたときなど、完了のタイムスタンプを表します。

この属性は、個々のアクティビティの期間(処理時間)を正確に計算するために不可欠です。タスクで実際に作業した時間とタスク間の待機時間を区別することで、詳細なボトルネック分析に役立ちます。

その重要性

正確なアクティビティ期間(処理時間)の計算を可能にし、プロセスの非効率なステップを特定するための鍵となります。

取得元

アトミックなイベントの場合、これはStartTimeと同じです。継続的なアクティビティの場合、データ内の対応する完了イベントを見つけることで導出されます。

2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
重大度
Severity
開発`アイテム`の`重大度レベル`。通常は`バグ`や`インシデント`向けです。
説明

重大度バグまたは課題の影響を示し、クリティカルからマイナーまであります。GitLabにはネイティブの重大度``フィールドがないため、これはほとんど常にラベル(例:「severity::1」、「severity::2」)を使用して実装されます。

この属性は、「重大度エスカレーション``トレンドダッシュボードおよび関連するKPIに不可欠です。ライフサイクルにおける重大度の変化を分析することで、当初過小評価されていた課題や、問題を悪化させるプロセスを浮き彫りにすることができます。

その重要性

作業の優先順位付けと、重大度の高いアイテムがより迅速に処理されるかどうかの分析に役立ちます。変更を追跡することで、「重大度エスカレーション頻度」KPIがサポートされます。

取得元

GitLab Issueに適用された「ラベル」から導出されます。「S1」、「S2」のようなラベルを重要度レベルとして解釈するためのマッピングが必要です。

1 - Critical2 - High3 - Medium4 - Low
開発項目タイプ
DevelopmentItemType
開発`アイテム`の分類。例えば、「機能」、「`バグ`」、「`タスク`」、「保守」など。
説明

この属性は、実行されている作業の性質を分類します。GitLabでは、これは一般的に課題ラベルを使用して実装されます。チームはラベルを使用して、新機能、欠陥解決、技術的負債、その他の作業タイプを区別します。

開発アイテムタイプによる分析は、異なる種類の作業プロセスフローサイクルタイムを比較することを可能にします。例えば、バグが機能開発よりも早く解決されるか、または技術的負債``タスクが異なるレビュープロセスに従うかを分析できます。

その重要性

プロセス作業タイプ別にセグメント化することで、特定の作業タイプが遅延、手戻り、または逸脱の傾向があるかどうかを特定するのに役立ちます。

取得元

通常、GitLabのIssueに適用される「ラベル」から導出されます。特定のラベルを標準化されたタイプに変換するためのマッピングロジックが必要です。

機能バグタスク`技術的負債`
`パイプライン``ステータス`
PipelineStatus
`CI/CDパイプライン`実行の`ステータス`。例えば、「成功」、「失敗」、「実行中」など。
説明

この属性は、コミットまたはマージリクエストに関連付けられたCI/CDパイプライン実行の結果を示します。GitLabでの一般的なステータスには、「running」、「pending」、「success」、「failed」、「canceled」、「skipped」などがあります。

このデータは、「手戻り作業と再実行分析」ダッシュボードにとって不可欠です。頻繁なパイプラインの失敗は、手戻り作業と遅延の重大な原因となる可能性があり、その頻度、場所、影響を分析することは、開発効率とコード品質を向上させるための鍵となります。

その重要性

自動ビルドとテストの成否を追跡し、手戻りループやコード品質、テスト自動化の問題点を浮き彫りにします。

取得元

GitLab CI/CDパイプラインAPI``レスポンスの「status」フィールドから取得されます。

success失敗runningキャンセル済み
サイクルタイム
CycleTime
開発`アイテム`の最初のアクティビティから最後のアクティビティまでの経過総時間。
説明

サイクルタイムは、ケースの合計期間を測定する計算されたメトリックです。通常、単一の開発項目について、最初のイベント(例:「Issue Created」)と最後のイベント(例:「Deployed to Production」)の間の時間差として計算されます。

これは、全体的なプロセス効率を測定するための主要なKPIです。「SDLC End-to-End Cycle Time」のようなダッシュボードの主要なメトリックであり、改善を追跡し、システム的な問題を示唆する可能性のある長期間実行中のケースを特定するために使用されます。

その重要性

これは、開発ライフサイクルのエンドツーエンドの効率を測定するコアプロセスマイニングKPIです。

取得元

プロセスマイニングツールによって、各一意のCaseIdの最大開始時刻(Maximum StartTime)から最小開始時刻(Minimum StartTime)を差し引くことで計算されます。

10日4時間23時間15分35 days
ソースシステム
SourceSystem
`データ`のソース元`システム`を特定します。
説明

この属性は、プロセスデータ発生源を指定します。このデータモデルの場合、は常に「GitLab」となります。

この属性を含めることは、計画にはJira、実行にはGitLabなど、複数のシステムからプロセスデータが結合される環境において極めて重要です。これにより、フィルタリングセグメンテーションが可能になり、データリネージの維持に役立ちます。

その重要性

データガバナンスや複数のエンタープライズシステムからのデータ統合時に不可欠な、データソースの明確性を保証します。

取得元

これは、データ変換プロセス中に追加される静的なGitLab」です。

GitLab
ターゲットブランチ
TargetBranch
`マージリクエスト`の宛先`ブランチ`の名前。
説明

ターゲットブランチは、変更がマージされるブランチです。例えば、「main」、「develop」、または「release/1.5」のようなリリースブランチです。これはあらゆるマージリクエストにとってコアとなる情報です。

ターゲットブランチによる分析は、異なる宛先にマージされるコードプロセス動作の違いを明らかにすることができます。例えば、「main」へのマージは、フィーチャーブランチへのマージよりも厳格な承認プロセスと長いサイクルタイムを持つ場合があります。また、本番デプロイメントを他のコード統合タイプと区別するのにも役立ちます。

その重要性

宛先ブランチによってプロセスが大きく異なるため、様々な開発およびリリースワークフローを区別するのに役立ちます。

取得元

GitLabマージリクエストAPI``レスポンスの「target_branch」フィールドから取得されます。

main開発release/v2.1.0hotfix/user-auth-bug
チーム名
TeamName
`プロジェクト`または`アサイニー`に関連付けられた開発チーム。
説明

チーム名とは、開発アイテムを担当するグループまたはスクワッドを指します。この情報は通常、GitLabの標準フィールドではなく、プロジェクトの命名規則、グループ構造、またはアサイニーを外部参照テーブルを使用してそれぞれのチームにマッピングすることによって導出されます。

この属性は、チームレベルでのプロセスパフォーマンスを分析するために使用されます。異なるチーム間での効率、ワークロードプロセスへの順守を比較するのに役立ち、「ステージ固有のボトルネック分析」のようなダッシュボードをチームベースの視点からサポートします。

その重要性

異なるチーム間でのパフォーマンス分析とプロセス比較を可能にし、チーム固有のボトルネックやベストプラクティスの特定に役立ちます。

取得元

多くの場合、GitLab外部で定義されたチーム構造にプロジェクト名アサイニーをマッピングするか、GitLabグループ階層から推測されます。

フロントエンド-Alphaバックエンドサービスプラットフォーム-`インフラ`
ハンドオフ待ち時間
HandoffWaitTime
異なる担当者によって実行された2つの連続するアクティビティ間の計算されたアイドル時間。
説明

このメトリックは、1つのアクティビティの完了から次のアクティビティの開始までのギャップの期間を計算するもので、特にアサイニーが変更された場合に測定されます。例えば、開発者が作業を終えてからレビュー担当者がコードレビューを開始するまでの時間を測定します。

これは、「平均引き継ぎ待ち時間KPIの主要メトリックです。リソース配分やチーム、個人間のコミュニケーションにおける隠れた非効率性を明らかにするのに役立ち、いかなるアクティブな作業の一部ではない遅延を浮き彫りにします。

その重要性

異なる個人またはチーム間の引き継ぎにおけるアイドル時間を定量化し、隠れた遅延とコミュニケーションのボトルネックを明らかにします。

取得元

プロセスマイニングツールによって計算されます。ケース内の連続するイベントを分析し、「Assignee」が異なるかどうかを確認し、その時間差を計算する必要があります。

1日2時間15分8時間
マージリクエスト`ステータス`
MergeRequestStatus
`イベント`に関連付けられた`マージリクエスト`の`ステータス`。例えば、「オープン済み」、「マージ済み」、「クローズ済み」など。
説明

この属性は、イベント発生時のマージリクエストMR)の状態を捕捉します。GitLab MRには、「opened」、「closed」、「merged」、「locked」という異なる状態があります。これは、全体的な開発アイテムステータスとは別です。

MR``ステータスの追跡は、SDLCコード統合フェーズを分析するために重要です。これは、「コードレビュー``サイクルタイムスループット」などのダッシュボードを直接サポートし、MR作成、レビュー、承認、マージ間の遅延を特定するのに役立ちます。

その重要性

コードレビューとマージプロセスの可視性を提供します。これらはSDLCにおいてしばしば重要なボトルネックとなります。

取得元

GitLabマージリクエストAPI``レスポンスの「state」フィールドから取得されます。

openedmergedクローズ済みlocked
マイルストーンの`タイトル`
MilestoneTitle
開発`アイテム`が割り当てられている`マイルストーン`または`スプリント`の`タイトル`。
説明

GitLabにおけるマイルストーンは、スプリントやリリースバージョンなど、特定の目標や時間枠に対する作業を追跡するために使用されます。この属性は、そのマイルストーンの名前またはタイトルを捕捉します。

この属性により、特定のスプリントや計画期間のコンテキスト内でプロセスパフォーマンスを分析できます。これにより、サイクルタイムがスプリントごとに改善されているかどうかを確認したり、プロセスビューをフィルタリングして、今後のリリースに関連する作業のみを表示したりすることができます。

その重要性

開発作業をスプリントやリリースなどの計画サイクルにリンクさせ、計画されたタイムボックスに対するパフォーマンス分析を可能にします。

取得元

GitLab課題またはマージリクエストAPI``レスポンスの「milestone.title」フィールドから取得されます。

2023年`Q4リリース``スプリント` 23.11`フェーズ`1: `MVP`
リリースバージョン
ReleaseVersion
デプロイメントに関連付けられた計画または実際のソフトウェアバージョン`タグ`。
説明

この属性は、開発アイテムが属する特定のソフトウェアリリースを識別します。GitLabでは、これはマイルストーン、保護されたタグ、またはリリース機能のエントリを介して関連付けることができます。

これは「リリーススケジュール順守追跡」ダッシュボードにとって不可欠です。実際のデプロイメント日付をリリースバージョンに関連付けられた計画日付と比較することで、組織はスケジュール達成能力を測定し、リリース遅延の原因を診断できます。

その重要性

開発項目を特定のソフトウェアリリースに接続します。これはリリース進捗とスケジュール順守を追跡する上で非常に重要です。

取得元

これはGitLabリリースgitタグの名前、またはリリース計画に使用されるマイルストーンタイトルから取得できます。

v1.2.0v3.0.0-beta2023.4.1
最終データ更新
LastDataUpdate
このイベントのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。
説明

この属性は、プロセスマイニング``データセット内でイベントデータが最後に抽出または更新された日付と時刻を記録します。これはイベントが発生したときではなく、イベントのレコードが最後に同期されたときを表します。

この情報は、データの鮮度を理解し、プロセス分析の適時性を検証するために不可欠です。これにより、ユーザーはダッシュボードKPIが最新のデータに基づいていると信頼し、ソースシステムと分析間の潜在的な遅延を把握することができます。

その重要性

データの鮮度に関する透明性を提供し、ユーザーがプロセス分析がどれだけ最新であるかを確実に認識できるようにします。

取得元

このtimestampは、データ抽出ツールまたはETLプロセスによって、データ``リフレッシュ時に生成および記録されます。

2024-05-21T02:00:00Z2024-05-22T02:00:00Z
処理時間
ProcessingTime
単一のアクティビティの期間。その終了時刻と開始時刻の差として計算されます。
説明

処理時間は、特定のアクティビティのアクティブな作業時間を測定するもので、アクティビティ間の待ち時間とは区別されます。これは、単一のイベントレコードについてEndTimeからStartTimeを引いて計算されます。瞬間的なイベントの場合、処理時間ゼロです。

このメトリックは、「ステージ固有のボトルネック分析」にとって重要です。コードレビューなどのステージ内のアクティビティ処理時間を集計することで、アナリストは実際に作業に費やされた時間を正確に判断でき、非効率なプロセスステップを特定するのに役立ちます。

その重要性

個々のアクティビティの期間を測定し、アクティブな作業時間とアイドル待ち時間を区別することで、正確なボトルネック分析に役立ちます。

取得元

プロセスマイニングツールによって、アクティビティの終了時刻(EndTime)と開始時刻(StartTime)の差として計算されます。

2時間30分0分3日8時間
手戻り
IsRework
アクティビティが手戻りループの一部であるかを示すブール値フラグです。
説明

この計算属性は、テストが既に開始された後に開発に戻るなど、プロセスにおいて後退するステップを表すアクティビティにフラグを付けます。このフラグのロジックは通常、特定のアクティビティシーケンスを検出することを含みます。例えば、同じケースに対して「開発開始」イベントが「パイプライン失敗」または「QAテスト開始」イベントの後に発生する場合などです。

この属性は、「手戻り作業と再実行分析」ダッシュボードおよび「テスト後の手戻り率」KPIを直接強化します。手戻り作業の容易なフィルタリングと定量化を可能にし、チームがその頻度、原因、プロジェクトタイムラインへの影響を理解するのに役立ちます。

その重要性

手戻りを直接的に指摘し定量化することで、プロセスの非効率性や品質問題の原因と影響を容易に分析できます。

取得元

プロセスマイニングツールによって、各ケースのアクティビティのシーケンスを分析し、手戻りを示すパターンを特定することで計算されます。

truefalse
開発項目ステータス
DevelopmentItemStatus
`イベント`発生時の開発`アイテム`の`ステータス`。例えば、「オープン」、「進行中」、「クローズ済み」など。
説明

この属性は、主要な作業アイテムの状態、通常はGitLab課題の状態を反映します。GitLab課題には「opened」または「closed」のstateがあり、よりきめ細かい``ステータスはスコープ付きラベル(例:「Status::Triage」、「Status::In-Dev」、「Status::In-Review」)を使用して管理されることがよくあります。

ステータス変更の追跡は、ケースライフサイクルを理解する上で重要です。これにより、アイテムが各状態にどのくらいの期間費やされたかを特定し、「SDLCエンドツーエンドサイクルタイム」などのダッシュボードでアクティブな作業や完了した作業をフィルタリングするために使用できます。

その重要性

ケース状態のスナップショットを提供し、様々なステージで費やされた時間の分析や、進行中作業と完了作業フィルタリングを可能にします。

取得元

主要なステータスは、GitLab``課題の「state」フィールド(「opened」、「closed」)から取得されます。よりきめ細かい``ステータスは、多くの場合ラベルから導出されます。

openedクローズ済み進行中審査中
必須 推奨 任意

ソフトウェア開発ライフサイクルアクティビティ

正確なプロセス発見とボトルネック特定のため、イベントログに記録すべき主要ステップとマイルストーンは次のとおりです。
4 推奨 8 任意
アクティビティ 説明
マージリクエストマージ済み
この`アクティビティ`は、`コードレビュー`および統合`プロセス`の正常な完了を示します。これは、ユーザーが`マージリクエスト`の`ブランチ`を`ターゲットブランチ`にマージしたときに発生する明示的な`イベント`です。
その重要性

これは、開発とレビューが完了したことを示す主要なマイルストーンです。開発サイクルタイムを測定するための終点であり、デプロイリードタイムを測定するための開始点として機能します。

取得元

これは、「merge_requests」テーブル内の「merged_at」timestampから捕捉される明示的なイベントです。マージ時にもシステムノートが生成されます。

取得

マージリクエストのmerged_atタイムスタンプを使用します。

イベントタイプ explicit
マージリクエスト作成済み
初期開発作業が完了し、`コード`がレビューと統合の準備が整ったことを示します。これは`GitLabワークフロー`における明示的な主要`イベント`であり、開発者が新しい`マージリクエスト`(`MR`)をオープンした際に捕捉されます。
その重要性

これは、開発からレビューおよびテストへの引き継ぎを示す重要なマイルストーンです。これは、コードレビューCI/CDパイプライン``サイクル全体を分析するためのエントリーポイントです。

取得元

これは、「merge_requests」テーブル内の「created_at」timestamp、またはMerge Requests APIを介して捕捉される明示的なイベントです。

取得

マージリクエストのcreated_atタイムスタンプを使用します。

イベントタイプ explicit
問題作成
この`アクティビティ`は、新しい作業`アイテム`(機能、`バグ`、`タスク`など)の作成を表し、開発ライフサイクルの開始を示します。`GitLab`でユーザーが新しい`課題`を作成したときに明示的に捕捉され、その作成`timestamp`が記録されます。
その重要性

これはエンドツーエンドプロセスの主要な開始イベントです。課題作成からデプロイメントまでの時間を分析することで、SDLCサイクルタイムの全体像を把握できます。

取得元

これは、「issues」テーブル内の「created_at」timestamp、またはIssues APIを介して捕捉される明示的なイベントです。システムノートも作成イベントを記録します。

取得

Issueのcreated_atタイムスタンプを使用します。

イベントタイプ explicit
本番環境にデプロイ済み
この`アクティビティ`は、`コード`がライブ本番環境に正常にデプロイされ、エンドユーザーが利用可能になったことを示します。これは、`GitLab CI/CDパイプライン`内の特定の「deploy to production」`ジョブ`が正常に完了したときに捕捉されます。
その重要性

これはプロセスの主要な終了イベントであり、価値が提供されたことを示します。エンドツーエンドのSDLCサイクルタイムとリリース頻度を測定するために不可欠です。

取得元

本番デプロイ用に特別に指定された成功したCI/CDジョブの「finished_at」タイムスタンプから取得されます。GitLabの環境機能がこれを明示的に追跡します。

取得

成功した本番デプロイのCIジョブからfinished_atタイムスタンプを使用します。

イベントタイプ explicit
`パイプライン`失敗
この`アクティビティ`は、`ビルドエラー`やテスト失敗など、`CI/CDパイプライン`実行がどの`ステージ`でも失敗したときに発生します。`GitLab`はすべての`パイプライン`の最終`ステータス`を明示的に記録するため、失敗を容易に特定できます。
その重要性

パイプラインの失敗は、手戻りの主要な原因です。その頻度、期間、原因を分析することで、品質課題、不安定なテスト、開発者へのフィードバックループにおけるボトルネックを特定できます。

取得元

「ci_pipelines」テーブル内のパイプラインレコードの「failed」statusによって識別されます。「finished_at」timestampは障害発生日時を示します。

取得

パイプラインレコードを「failed」ステータスでフィルタリングし、「finished_at」タイムスタンプを使用します。

イベントタイプ explicit
`パイプライン`開始
`ビルド`、テスト、セキュリティ`スキャン`を通常実行する`自動化されたCI/CDパイプライン`の開始を表します。`GitLab`は、`コミット`や`MR`の作成などによって`パイプライン`がトリガーされるたびに、開始`timestamp`を持つ`パイプライン`レコードを明示的に作成します。
その重要性

パイプライン実行の追跡は、自動化されたテストおよび統合プロセスの健全性と効率を監視するために不可欠です。自動化された``検証にどれだけの時間が費やされているかを特定するのに役立ちます。

取得元

「ci_pipelines」テーブル内のパイプラインレコードの「created_at」または「started_at」タイムスタンプ、あるいはパイプラインAPIを通じて取得されます。

取得

MRのブランチに関連付けられたパイプライン実行レコードからタイムスタンプを使用します。

イベントタイプ explicit
コードレビュー開始
`マージリクエスト`の`ピアレビュープロセス`の開始を示します。この`イベント`は、作成者以外の人物による最初のコメントや`スレッド`など、最初のレビュー関連`アクション`から推測されます。
その重要性

MR作成からレビュー開始までの時間を測定することで、キューイングの遅延が明らかになります。この待ち時間を短縮することは、コードレビュー``サイクル全体を短縮するための鍵です。

取得元

MRの作成者以外の人物によるマージリクエスト上の最初のコメントまたはレビュースレッドtimestampから推測されます。このデータシステムノートまたはNotes APIを通じて利用可能です。

取得

MRの作成者以外のユーザーによる最初のコメントのtimestampを見つけます。

イベントタイプ inferred
デプロイメント開始
`ステージング`や本番環境などの特定の環境に`コード`をリリースする`プロセス`の開始を表します。`GitLab`では、これは`CI/CDパイプライン`内の「deploy」`ジョブ`の開始に対応します。
その重要性

デプロイメントの開始を追跡することは、デプロイメントフェーズの期間を特定するのに役立ちます。デプロイリードタイムを測定し最適化するために不可欠です。

取得元

デプロイジョブとして設定されたCI/CDジョブの「started_at」タイムスタンプから取得されます。これはGitLabの環境およびデプロイ機能の一部です。

取得

デプロイタスクのCIジョブログからstarted_atタイムスタンプを使用します。

イベントタイプ explicit
承認が追加されました
レビュアーによる`マージリクエスト`内の`コード`変更の正式な承認を表します。これは、`GitLab`でユーザーが「Approve」`ボタン`をクリックしたときに捕捉される明示的な`イベント`です。
その重要性

承認は重要な品質ゲートです。これらを追跡することで、必要な承認を得るのにかかる時間を分析し、レビューポリシーへのコンプライアンスを確保するのに役立ちます。

取得元

マージリクエストの承認イベントから取得されます。これらは承認APIを通じて利用可能であるか、MRの履歴で確認できます。

取得

マージリクエスト承認イベントログからタイムスタンプを使用します。

イベントタイプ explicit
課題クローズ済み
作業`アイテム`の最終的な管理上の`クローズ`を表し、通常は変更がデプロイされ検証された後に行われます。これは、ユーザーが`GitLab`で課題を`クローズ`したときに捕捉される明示的な`イベント`です。
その重要性

Issueをクローズすることは、関連するすべての作業の最終的な終了を意味することがよくあります。これをデプロイ時間と比較することで、デプロイ後の検証や管理プロセスにおける遅延が明らかになる場合があります。

取得元

これは、「issues」テーブル内の「closed_at」timestamp、または対応するシステムノートから捕捉される明示的なイベントです。

取得

Issueのclosed_atタイムスタンプを使用します。

イベントタイプ explicit
課題割り当て済み
課題が特定の開発者またはチームに割り当てられたことを表し、作業の`オーナーシップ`が確立されたことを示します。これは、`GitLab`が課題の`アサイニー``フィールド`が入力または変更されるたびに`ログ`に記録する明示的な`イベント`です。
その重要性

割り当てを追跡することは、リソース配分、チームワークロード、および引き継ぎ時間を分析するために不可欠です。作業が作成されてから引き取られるまでの遅延を特定するのに役立ちます。

取得元

GitLabのIssueのシステムノートから取得されます。これは「assignee」が追加または変更されたときに記録されます。イベントタイムスタンプはノートに記録されます。

取得

Issueのシステムノートから「担当者変更」イベントを抽出します。

イベントタイプ explicit
開発開始
この`アクティビティ`は、`課題`に対するアクティブな`コーディング`作業の開始を示します。`GitLab`には明示的な「開発開始」`ボタン`がないため、これは通常、`課題`に関連付けられた`ブランチ`にプッシュされた最初の`コードコミット`から推測されます。
その重要性

価値付加開発作業の正確な開始点を特定し、純粋なコーディングフェーズを正確に測定し、計画またはキュー時間から分離することを可能にします。

取得元

課題に関連付けられたフィーチャーブランチ上の最初のコミットtimestampを見つけることで推測されます。これには、課題とブランチのリンクが必要であり、多くの場合、命名規則やメタデータを介して行われます。

取得

課題IDに関連付けられたブランチで最初のコミットのtimestampを見つけます。

イベントタイプ inferred
推奨 任意

抽出ガイド

`GitLab`から`データ`を取得する方法