ソフトウェア開発ライフサイクルのデータテンプレート
ソフトウェア開発ライフサイクルのデータテンプレート
- 収集を推奨する属性
- 追跡すべき主要なアクティビティ
- 抽出方法
ソフトウェア開発ライフサイクルの属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
Activity
|
'Issue Created'や'Merge Request Merged'など、発生した特定のプロセスステップまたはイベントの名称です。 | ||
|
説明
アクティビティ属性は、開発項目に対して発生する個別のイベントを記録します。GitLabでは単一のフィールドとして保存されず、Issues、Merge Requests、CI/CD Pipelinesにまたがるさまざまなアクションやタイムスタンプフィールドから導出されます。たとえば、Issueの作成、コミットのプッシュ、パイプラインの失敗、Merge Requestの承認は、それぞれ個別のアクティビティです。 この属性は、プロセスマップの作成、ワークフローの可視化、イベントの順序と頻度の分析に欠かせません。ステップ間の逸脱やボトルネック、一般的なプロセス経路の特定に使用します。
重要な理由
プロセスマップ上のステップを定義し、エンドツーエンドの開発ワークフローを可視化・分析できるようにします。
入手先
GitLabのイベントストリームにあるイベント種別や状態変更から導出します。または、IssuesやMerge Requestsの'created_at'、'merged_at'、'closed_at'などのタイムスタンプフィールドを解釈して取得します。
例
Issueの作成開発開始Merge Requestのマージパイプライン失敗本番環境へのデプロイ完了
|
|||
|
開始時刻
StartTime
|
アクティビティまたはイベントが開始した時点を示すタイムスタンプです。 | ||
|
説明
StartTimeは、特定のアクティビティが発生した正確な日時を示します。GitLabのイベントでは、さまざまなタイムスタンプフィールドから取得します。たとえば、'Issue Created'アクティビティのStartTimeはIssueの'created_at'タイムスタンプであり、'Merge Request Merged'アクティビティのStartTimeはMerge Requestの'merged_at'タイムスタンプです。 このタイムスタンプは、プロセスマイニングにおける中核的な時間要素です。イベントを時系列に並べ、アクティビティ間の所要時間を計算し、サイクルタイムを測定し、時間の経過に伴うプロセスパフォーマンスを分析するために使用します。
重要な理由
イベントの時系列を提供し、時間に基づくすべての指標の計算とプロセスフローの把握に欠かせません。
入手先
Issueの'created_at'、'updated_at'、'closed_at'や、Merge Requestの'merged_at'など、GitLabのさまざまなタイムスタンプフィールドから抽出します。
例
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
|
|||
|
開発項目
DevelopmentItem
|
機能、バグ修正、Taskなど、作業単位を一意に識別するIDであり、主要なケース識別子として使用されます。 | ||
|
説明
開発項目は、ソフトウェア開発ライフサイクルを通じて進む、追跡可能な1つの作業単位を表します。作成から最終デプロイまでの関連アクティビティを1つの一貫したケースとして結び付けます。GitLabでは通常、プロジェクト内で一意なIssueの内部ID(IID)で表されます。 開発項目単位で分析すると、エンドツーエンドのサイクルタイム測定、ボトルネックの特定、プロセス適合性の確認が可能になります。コンセプトから本番環境まで、作業がどれだけ効率的に提供されているかを把握する基盤になります。
重要な理由
これはすべてのプロセスイベントを結び付ける基本的なケース識別子であり、任意の作業項目のライフサイクル全体を追跡できます。
入手先
通常はGitLab Issueの内部ID(IID)です。Issues APIのレスポンスにある'iid'フィールドで確認できます。
例
1024512PRJ-2345
|
|||
|
プロジェクト名
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
|
|||
|
担当者
Assignee
|
イベント発生時点でIssueまたはMerge Requestに割り当てられていたユーザーです。 | ||
|
説明
担当者は、プロセスの特定時点で作業項目を担当する開発者またはユーザーです。GitLabでは、IssueまたはMerge Requestの 担当者単位の分析は、「開発者の作業負荷とリソース配分」ダッシュボードに欠かせません。リソースの利用状況、負荷が集中している個人やチーム、担当者間の引き継ぎを分析できます。
重要な理由
誰が作業を行ったかを追跡し、作業負荷の分析、リソース配分の効率化、引き継ぎによる遅延の特定を可能にします。
入手先
GitLabのIssues APIおよびMerge Requests APIのレスポンスにある'assignee.username'または'assignees'フィールドから取得します。
例
jdoeasmithr.williams
|
|||
|
終了時刻
EndTime
|
アクティビティまたはイベントが完了した時点を示すタイムスタンプです。 | ||
|
説明
EndTimeは、アクティビティが完了した正確な日時を示します。'Issue Created'のようなGitLabの多くの単発イベントでは、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に付けられた'labels'から導出します。'S1'や'S2'などのラベルを重大度レベルとして解釈するためのマッピングが必要です。
例
1:重大2:高3:中4:低
|
|||
|
開発項目種別
DevelopmentItemType
|
'Feature'、'Bug'、'Task'、'Maintenance'など、開発項目の分類です。 | ||
|
説明
この属性は、実施している作業の種類を分類します。GitLabでは通常、Issueに付けたラベルで管理します。チームはラベルを使って、新機能、欠陥修正、技術的負債、その他の作業種別を区別します。 開発項目種別で分析すると、作業の種類ごとにプロセスフローやサイクルタイムを比較できます。たとえば、機能開発よりもバグ修正のほうが速いか、技術的負債のTaskが異なるレビュープロセスをたどるかを分析できます。
重要な理由
作業種別でプロセスを分けることで、特定の作業が遅延、手戻り、逸脱を起こしやすいかを把握できます。
入手先
通常は、GitLab Issueに付けられた'labels'から導出します。特定のラベルを標準化された種別に変換するマッピングロジックが必要です。
例
機能バグタスク技術的負債
|
|||
|
Merge Requestステータス
MergeRequestStatus
|
イベントに関連付けられたMerge Requestのステータスです。'Opened'、'Merged'、'Closed'などがあります。 | ||
|
説明
この属性は、イベント発生時点におけるMerge Request(MR)の状態を記録します。GitLabのMRには、'opened'、'closed'、'merged'、'locked'という個別の状態があります。これは、開発項目全体のステータスとは別のものです。 MRステータスの追跡は、SDLCのコード統合工程を分析するうえで欠かせません。「コードレビューサイクルタイムとスループット」などのダッシュボードを支え、MRの作成、レビュー、承認、マージの間にある遅延を特定できます。
重要な理由
コードレビューとマージのプロセスを可視化します。この工程は、SDLCにおける重要なボトルネックになることがよくあります。
入手先
GitLab Merge Requests APIのレスポンスにある'state'フィールドから取得します。
例
オープンマージ済みクローズロック済み
|
|||
|
サイクルタイム
CycleTime
|
開発項目の最初のアクティビティから最後のアクティビティまでに経過した合計時間です。 | ||
|
説明
サイクルタイムは、ケースの合計所要時間を測定する計算指標です。通常は、1つの開発項目における最初のイベント(例:「Issue作成」)と最後のイベント(例:「本番環境へのデプロイ」)の時間差として計算します。 プロセス全体の効率を測定する主要なKPIです。「SDLCエンドツーエンドサイクルタイム」などのダッシュボードで中心的な指標として使い、改善状況の追跡や、システム上の問題を示す可能性がある長時間のケースの特定に役立てます。
重要な理由
開発ライフサイクルのエンドツーエンドの効率を測定する、プロセスマイニングの主要KPIです。
入手先
一意のCaseIdごとに、最小のStartTimeを最大のStartTimeから差し引いてプロセスマイニングツールが計算します。
例
10日4時間23時間15分35日
|
|||
|
ソースシステム
SourceSystem
|
データの取得元となったシステムを識別します。 | ||
|
説明
この属性は、プロセスデータの取得元を示します。このデータモデルでは、値は常に'GitLab'になります。 計画にJira、実行にGitLabを使う場合など、複数のシステムからプロセスデータを統合する環境では、この属性が欠かせません。フィルタリングやセグメント化に利用でき、データの系譜の維持にも役立ちます。
重要な理由
データの取得元を明確にし、データガバナンスや複数のエンタープライズシステムからのデータ統合に役立ちます。
入手先
データ変換処理中に追加される静的な値'GitLab'です。
例
GitLab
|
|||
|
チーム名
TeamName
|
プロジェクトまたは担当者に関連付けられた開発チームです。 | ||
|
説明
チーム名は、開発項目を担当するグループまたはスクワッドを表します。通常、GitLabの標準フィールドではなく、プロジェクトの命名規則やグループ構成から導出するか、外部参照テーブルを使って担当者を所属チームに対応付けます。 この属性は、チーム単位でプロセスパフォーマンスを分析するために使用します。チームごとの効率、作業負荷、プロセス遵守率を比較でき、チーム単位で「工程別ボトルネック分析」などのダッシュボードを確認する際に役立ちます。
重要な理由
チーム間のパフォーマンス分析とプロセス比較を可能にし、チーム固有のボトルネックや優れた実践方法の特定に役立ちます。
入手先
多くの場合、GitLab外で定義されたチーム構成に基づき、プロジェクト名または担当者をチームに対応付けて導出します。GitLabのグループ階層から推定する場合もあります。
例
Frontend-AlphaBackend-ServicesPlatform-Infra
|
|||
|
パイプラインステータス
PipelineStatus
|
CI/CDパイプライン実行のステータスです。'Success'、'Failed'、'Running'などがあります。 | ||
|
説明
この属性は、コミットまたはMerge Requestに関連付けられたCI/CDパイプライン実行の結果を示します。GitLabで一般的なステータスには、'running'、'pending'、'success'、'failed'、'canceled'、'skipped'があります。 このデータは、「手戻りと再実行の分析」ダッシュボードに欠かせません。パイプラインの頻繁な失敗は、手戻りや遅延の大きな原因になる可能性があります。発生頻度、発生箇所、影響を分析することは、開発効率とコード品質の向上に重要です。
重要な理由
自動ビルドとテストの成功・失敗を追跡し、手戻りループやコード品質・テスト自動化に関する問題を明らかにします。
入手先
GitLab CI/CD Pipelines APIのレスポンスにある'status'フィールドから取得します。
例
成功失敗実行中キャンセル済み
|
|||
|
マイルストーン名
MilestoneTitle
|
開発項目が割り当てられているマイルストーンまたはスプリントの名前です。 | ||
|
説明
GitLabのマイルストーンは、スプリントやリリースバージョンなど、特定の目標や期間に対する作業の進捗を追跡するために使います。この属性には、マイルストーンの名前またはタイトルが記録されます。 この属性を使うと、特定のスプリントや計画期間におけるプロセスのパフォーマンスを分析できます。スプリントごとにサイクルタイムが改善しているかを確認したり、今後のリリースに関係する作業だけをプロセスビューに表示したりできます。
重要な理由
開発作業をスプリントやリリースなどの計画サイクルに関連付け、計画した期間に対するパフォーマンスを分析できるようにします。
入手先
GitLab IssuesまたはMerge Requests APIのレスポンスに含まれる「milestone.title」フィールドから取得します。
例
2023年第4四半期リリーススプリント23.11フェーズ1:MVP
|
|||
|
リリースバージョン
ReleaseVersion
|
デプロイに関連付けられた、計画上または実際のソフトウェアバージョンタグです。 | ||
|
説明
この属性は、開発項目が含まれる具体的なソフトウェアリリースを識別します。GitLabでは、マイルストーン、保護されたタグ、またはReleases機能のエントリを通じて関連付けることができます。 これは「リリーススケジュール遵守状況」ダッシュボードに欠かせません。リリースバージョンに設定した計画日と実際のデプロイ日を比較することで、組織がスケジュールを守れているかを測定し、リリース遅延の原因を特定できます。
重要な理由
開発項目を特定のソフトウェアリリースに関連付けます。リリースの進捗とスケジュール遵守状況を追跡するうえで重要です。
入手先
GitLab Releases、gitタグの名前、またはリリース計画に使うマイルストーンのタイトルから取得できます。
例
v1.2.0v3.0.0-beta2023.4.1
|
|||
|
最終データ更新日時
LastDataUpdate
|
このイベントのデータがソースシステムから最後に更新された時点を示すタイムスタンプです。 | ||
|
説明
この属性は、イベントデータがプロセスマイニングデータセットに最後に抽出または更新された日時を記録します。イベントが発生した日時ではなく、イベントの記録が最後に同期された日時を示します。 データの鮮度を把握し、プロセス分析の適時性を検証するうえで重要な情報です。ダッシュボードやKPIが最新のデータに基づいていることを確認しやすくなり、ソースシステムと分析結果の間に生じる可能性がある遅延も把握できます。
重要な理由
データの鮮度を明確にし、プロセス分析がどの程度最新の状態かを把握できるようにします。
入手先
データ更新時に、データ抽出ツールまたはETLプロセスによって生成・記録されるタイムスタンプです。
例
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
|
対象ブランチ
TargetBranch
|
Merge Requestの変更先ブランチの名称です。 | ||
|
説明
対象ブランチは、変更をマージする先のブランチです。たとえば、'main'、'develop'、'release/1.5'のようなリリースブランチがあります。Merge Requestに欠かせない基本情報です。 対象ブランチ単位で分析すると、異なる宛先にマージされるコードのプロセスの違いを明らかにできます。たとえば、'main'へのマージでは、機能ブランチへのマージよりも厳格な承認プロセスが適用され、サイクルタイムが長くなる場合があります。本番デプロイとその他のコード統合を区別する際にも役立ちます。
重要な理由
さまざまな開発ワークフローやリリースワークフローを区別できます。宛先ブランチによってプロセスが大きく異なる場合があるためです。
入手先
GitLab Merge Requests APIのレスポンスにある'target_branch'フィールドから取得します。
例
maindeveloprelease/v2.1.0hotfix/user-auth-bug
|
|||
|
引き継ぎ待ち時間
HandoffWaitTime
|
異なる担当者が実行する連続した2つのアクティビティの間に発生する、計算上のアイドル時間です。 | ||
|
説明
担当者が変わる場合に、1つのアクティビティの完了から次のアクティビティの開始までの空白時間を計算します。たとえば、開発者が作業を終えてからレビュアーがコードレビューを開始するまでの時間を測定します。 「平均引き継ぎ待ち時間」KPIの中心となる指標です。チームや個人間のリソース配分とコミュニケーションに潜む非効率を明らかにし、実作業には含まれない遅延を把握できます。
重要な理由
異なる担当者やチーム間の引き継ぎ中に発生するアイドル時間を定量化し、見えにくい遅延やコミュニケーション上のボトルネックを明らかにします。
入手先
プロセスマイニングツールが計算します。ケース内の連続するイベントを分析し、「Assignee」が異なるかを確認したうえで時間差を算出します。
例
1日2時間15分8時間
|
|||
|
手戻りかどうか
IsRework
|
アクティビティが手戻りループの一部かどうかを示すブール値のフラグです。 | ||
|
説明
この計算属性は、テスト開始後に開発へ戻る場合など、プロセスが後戻りするステップを示します。通常は、同じケースで「パイプライン失敗」または「QAテスト開始」の後に「開発開始」が発生するといった、特定のアクティビティの順序を検出して判定します。 この属性は、「手戻りと再実行の分析」ダッシュボードと「テスト後の手戻り率」KPIに直接使われます。手戻りを簡単に絞り込み、件数や割合を把握できるため、チームは手戻りの頻度、原因、プロジェクト期間への影響を理解できます。
重要な理由
手戻りを直接検出して定量化し、プロセスの非効率や品質上の問題の原因と影響を分析しやすくします。
入手先
ケースごとのアクティビティの順序を分析し、手戻りを示すパターンを特定してプロセスマイニングツールが計算します。
例
truefalse
|
|||
|
開発項目ステータス
DevelopmentItemStatus
|
イベント発生時点における開発項目のステータスです。'Open'、'In Progress'、'Closed'などがあります。 | ||
|
説明
この属性は、主要な作業項目、通常はGitLabのIssueの状態を示します。GitLab Issueには'opened'または'closed'のいずれかの ステータスの変更を追跡することは、ケースのライフサイクルを把握するうえで重要です。各状態に滞在した時間を特定でき、「SDLCエンドツーエンドサイクルタイム」などのダッシュボードで、進行中または完了した作業を絞り込む際にも利用できます。
重要な理由
ケースの状態を示すスナップショットを提供し、各工程に費やした時間の分析や、進行中と完了済みの作業の絞り込みを可能にします。
入手先
主要なステータスは、GitLab Issueの'state'フィールド('opened'、'closed')から取得します。より詳細なステータスは、通常ラベルから導出します。
例
オープンクローズ対応中レビュー中
|
|||
ソフトウェア開発ライフサイクルのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
Issueの作成
|
このアクティビティは開発ライフサイクルの開始を示し、機能、バグ、Taskなど、新しい作業項目の作成を表します。GitLabでユーザーが新しいIssueを作成すると明示的に記録され、作成時刻が保存されます。 | ||
|
重要な理由
これはエンドツーエンドプロセスの主要な開始イベントです。Issueの作成からデプロイまでの時間を分析することで、SDLCのサイクルタイム全体を把握できます。
入手先
これは、'issues'テーブルの'created_at'タイムスタンプ、またはIssues APIから取得する明示的なイベントです。システムノートにも作成イベントが記録されます。
取得
Issueの'created_at'タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
Merge Requestのマージ
|
コードレビューと統合プロセスが正常に完了したことを示します。ユーザーがMerge Requestのブランチを対象ブランチにマージした際に発生する明示的なイベントです。 | ||
|
重要な理由
開発とレビューが完了したことを示す主要なマイルストーンです。開発サイクルタイムの測定では終了点となり、デプロイまでのリードタイムの測定では開始点になります。
入手先
これは、'merge_requests'テーブルの'merged_at'タイムスタンプから取得する明示的なイベントです。マージ時にはシステムノートも生成されます。
取得
Merge Requestの'merged_at'タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
Merge Requestの作成
|
初期の開発作業が完了し、コードがレビューと統合の準備を終えたことを示します。GitLabワークフローの明示的な主要イベントであり、開発者が新しいMerge Request(MR)を作成した時点で記録されます。 | ||
|
重要な理由
開発からレビューとテストへの引き継ぎを示す重要なマイルストーンです。コードレビューとCI/CDパイプラインのサイクル全体を分析する際の開始点になります。
入手先
これは、'merge_requests'テーブルの'created_at'タイムスタンプ、またはMerge Requests APIから取得する明示的なイベントです。
取得
Merge Requestの'created_at'タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
本番環境へのデプロイ完了
|
コードが稼働中の本番環境へ正常にデプロイされ、エンドユーザーが利用できる状態になったことを示します。GitLabのCI/CDパイプラインで、本番環境へのデプロイ専用ジョブが正常に完了した際に記録されます。 | ||
|
重要な理由
これはプロセスの主要な終了イベントであり、価値が提供されたことを示します。SDLCのエンドツーエンドのサイクルタイム全体とリリース頻度を測定するうえで欠かせません。
入手先
本番デプロイ専用のCI/CDジョブが正常に完了した時点の'finished_at'タイムスタンプから取得します。GitLabのEnvironments機能で明示的に追跡されます。
取得
本番デプロイに成功したCIジョブの'finished_at'タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
Issueのクローズ
|
通常、変更のデプロイと検証が完了した後に行われる、作業項目の最終的な事務処理上のクローズを表します。GitLabでユーザーがIssueをクローズした際に、明示的なイベントとして記録されます。 | ||
|
重要な理由
Issueのクローズは、関連するすべての作業が最終的に完了したことを示す場合があります。デプロイ時刻と比較することで、デプロイ後の検証や事務処理における遅延を明らかにできます。
入手先
これは、'issues'テーブルの'closed_at'タイムスタンプ、または対応するシステムノートから取得する明示的なイベントです。
取得
Issueの'closed_at'タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
Issueの割り当て
|
Issueを特定の開発者またはチームに割り当て、作業の担当者が決まったことを示します。GitLabでは、Issueの担当者フィールドに値が設定または変更された際に、明示的なイベントとして記録されます。 | ||
|
重要な理由
割り当てを追跡することは、リソース配分、チームの作業負荷、引き継ぎ時間を分析するうえで重要です。作業が作成されてから着手されるまでの遅延を特定できます。
入手先
Issueのシステムノートから取得します。システムノートには、'assignee'が追加または変更された時点が記録されます。イベントのタイムスタンプはノートに保存されます。
取得
Issueのシステムノートから'assignee changed'イベントを抽出します。
イベントタイプ
explicit
|
|||
|
コードレビュー開始
|
Merge Requestのピアレビューが始まったことを示します。通常は、作成者以外のユーザーが投稿した最初のコメントやスレッドなど、レビューに関する最初のアクションから推定します。 | ||
|
重要な理由
MRの作成からレビュー開始までの時間を測定すると、待ち行列による遅延が明らかになります。この待ち時間を短縮することは、コードレビュー全体のサイクルを短くするうえで重要です。
入手先
MR作成者以外のユーザーがMerge Requestに投稿した最初のコメントまたはレビュースレッドのタイムスタンプから推定します。このデータはシステムノートまたはNotes APIから取得できます。
取得
MR作成者以外のユーザーによる、MRへの最初のコメントのタイムスタンプを取得します。
イベントタイプ
inferred
|
|||
|
デプロイ開始
|
ステージングや本番環境など、特定の環境へコードをリリースするプロセスの開始を表します。GitLabでは、CI/CDパイプライン内の'deploy'ジョブが開始された時点に相当します。 | ||
|
重要な理由
デプロイの開始を追跡すると、デプロイ工程の所要時間を切り分けられます。デプロイまでのリードタイムを測定・最適化するうえで重要です。
入手先
デプロイジョブとして設定されたCI/CDジョブの'started_at'タイムスタンプから取得します。GitLabのEnvironments and Deployments機能の一部です。
取得
デプロイTaskに対応するCIジョブログの'started_at'タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
パイプライン失敗
|
ビルドエラーやテスト失敗など、CI/CDパイプラインの実行がいずれかの段階で失敗した際に発生するアクティビティです。GitLabでは、すべてのパイプラインの最終ステータスが明示的に記録されるため、失敗を簡単に特定できます。 | ||
|
重要な理由
パイプラインの失敗は、手戻りの主な原因です。発生頻度、所要時間、原因を分析することで、品質上の問題、不安定なテスト、開発者へのフィードバックループにおけるボトルネックを特定できます。
入手先
'ci_pipelines'テーブルのパイプラインレコードにある'failed'ステータスで特定します。'finished_at'タイムスタンプは、失敗が発生した時刻を示します。
取得
'failed'ステータスのパイプラインレコードを抽出し、'finished_at'タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
パイプライン開始
|
通常、ビルド、テスト、セキュリティスキャンを実行する自動CI/CDパイプラインの開始を表します。GitLabでは、コミットやMRの作成などによってパイプラインが起動されると、開始時刻を含むパイプラインレコードが明示的に作成されます。 | ||
|
重要な理由
パイプラインの実行を追跡することは、自動テストと統合プロセスの健全性や効率を監視するうえで欠かせません。自動検証にどれだけ時間がかかっているかを特定できます。
入手先
'ci_pipelines'テーブルのパイプラインレコード、またはPipelines APIにある'created_at'もしくは'started_at'タイムスタンプから取得します。
取得
MRのブランチに関連付けられたパイプライン実行レコードのタイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
承認の追加
|
レビュー担当者がMerge Requestのコード変更を正式に承認したことを示します。ユーザーが「Approve」ボタンをクリックした際に、GitLabが明示的なイベントとして記録します。 | ||
|
重要な理由
承認は品質ゲートとして重要です。承認に必要なサインオフの所要時間を分析し、レビュー方針へのコンプライアンスを確認できます。
入手先
Merge Requestの承認イベントから取得します。Approvals APIで取得できるほか、MRの履歴でも確認できます。
取得
Merge Requestの承認イベントログにあるタイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
開発開始
|
このアクティビティは、Issueに対する実際のコーディング作業の開始を示します。GitLabには明示的な「開発開始」ボタンがないため、通常はIssueに関連付けられたブランチへ最初のコードコミットがプッシュされた時点から推定します。 | ||
|
重要な理由
価値を生み出す開発作業が実際に始まった時点を特定し、計画や待機時間と分けて、純粋なコーディング工程を正確に測定できます。
入手先
Issueに関連付けられた機能ブランチで最初のコミットのタイムスタンプを特定して推定します。Issueとブランチの関連付けには、通常、命名規則やメタデータを使用します。
取得
Issue IDに関連付けられたブランチで、最初のコミットのタイムスタンプを取得します。
イベントタイプ
inferred
|
|||
抽出ガイド
準備はできましたか?
このテンプレートでデータを準備し、ソフトウェア開発ライフサイクルの改善を始めてください。今すぐプロセスを変えていきましょう。
ソフトウェア開発ライフサイクルを改善:今すぐ最適化を開始
SDLCのボトルネックをなくし、サイクルタイムを30%短縮し、品質を高めます。
クレジットカードは不要です。すぐに最適化を始められます。