バリューストリーム分析

バリューストリーム分析は、ソフトウェア開発プロセスの各ステージの期間を計算します。アイデアから本番環境への移行にかかる時間を、マージリクエストまたはイシューイベントを追跡することで測定できます。

バリューストリーム分析を使用して、以下を特定します:

• アイデアから本番環境への移行にかかる時間。
• 特定のプロジェクトの開発速度。
• ソフトウェア開発プロセスにおけるボトルネック。
• 長時間実行されているイシューまたはマージリクエスト。
• ソフトウェア開発ライフサイクルの速度を低下させる要因。

バリューストリーム分析は、企業が以下を行うのに役立ちます:

• エンドツーエンドのDevSecOpsワークストリームを可視化します。
• 非効率を特定し、解決します。
• ワークストリームを最適化して、より速く、より多くの価値を提供します（例: マージリクエストのレビュー時間を短縮する）。

クリックスルーデモについては、バリューストリーム管理の製品ツアーを参照してください。

バリューストリーム分析は階層構造を持っています:

• バリューストリームには、バリューストリームステージリストが含まれています。
• 各バリューストリームステージリストには、1つ以上のステージが含まれています。
• 各ステージは、2つのイベントで定義されます。

メトリクス

バリューストリーム分析の概要ページには、プロジェクトとグループのDevSecOpsライフサイクルパフォーマンスの主要なメトリクスが表示されます。

ライフサイクルメトリクス

バリューストリーム分析には、次のライフサイクルメトリクスが含まれます:

• リードタイム: イシューの作成から完了までの時間の中央値。
• サイクルタイム: イシューがマージリクエストのコミットメッセージで最初に参照された時点から、その参照されたイシューがクローズされるまでの期間の中央値。コミットメッセージにイシュー番号（例: #123）の後に#を含める必要があります。そうしないとデータは表示されません。マージリクエストは最初のコミット後に作成されるため、サイクルタイムは通常リードタイムよりも短くなります。
• 新しいイシュー: 作成された新しいイシューの数。
• デプロイ: 本番環境へのデプロイの合計数。

DORAメトリクス

バリューストリーム分析には、以下のDORAメトリクスが含まれています:

• デプロイ頻度
• 変更のリード時間
• サービス復旧時間
• 変更失敗率

DORAメトリクスは、DORA APIからのデータに基づいて計算されます。

GitLab PremiumまたはUltimateサブスクリプションをお持ちの場合:

• 成功したデプロイの数はDORAデータで計算されます。
• データは環境と環境のプランに基づいてフィルタリングされます。

バリューストリーム

バリューストリームは、顧客に価値を提供する作業プロセス全体です。バリューストリームは、ステージのコンテナオブジェクトです。グループごとに複数のバリューストリームを設定して、DevOpsライフサイクルのさまざまな側面に焦点を当てることができます。

バリューストリームステージ

ステージは、ステージ名などの追加メタデータを含むイベントペア（開始イベントと終了イベント）を表します。バリューストリーム分析を組み込みのデフォルトステージとともに使用でき、これらのステージは並べ替えたり非表示にしたりできます。特定のソフトウェア開発ワークフローに合わせたカスタムステージを作成して追加することもできます。

バリューストリームステージイベント

イベントは、ステージがいつ開始し、いつ終了するかを定義する構成要素です。各イベントには開始時刻と終了時刻があります:

• 開始イベント時刻は、ステージで作業が開始されるとき（例: イシューが作成されたとき）を示します。
• 終了イベント時刻は、ステージで作業が完了するとき（例: イシューがクローズされたとき）を示します。

GitLabは、この式を使用して、開始イベント時刻と終了イベント時刻に基づいてステージの期間を計算します: ステージ期間 = 終了イベント時刻 - 開始イベント時刻

バリューストリーム分析は、次のイベントをサポートしています:

• イシュークローズ
• イシュー作成
• イシューが初めてボードに追加された
• イシューが初めてイテレーションに追加された
• イシューが初めて割り当てられた
• イシューが初めてマイルストーンに関連付けられた
• イシューが初めてコミットで言及された
• イシューラベル追加
• イシューラベル削除
• マージリクエストクローズ
• マージリクエスト作成
• マージリクエストが初めて割り当てられた
• マージリクエストが初めてコミットされた
• マージリクエストが初めて本番環境にデプロイされた
• マージリクエストラベル追加
• マージリクエストラベル削除
• マージリクエストが最後に承認された
• マージリクエストの最後のビルドが完了した
• マージリクエストの最後のビルドが開始された
• マージリクエストがマージされた
• マージリクエストのレビュアーが初めて割り当てられた

ステージイベントに関するアイデアやフィードバックは、イシュー520962で共有できます。

ステージの測定

バリューストリーム分析は、各ステージをその開始イベントから終了イベントまで測定します。終了イベントに到達したアイテムのみが、ステージ時間計算に含まれます。

デフォルトでは、ブロックされたイシューはライフサイクル概要に含まれません。ただし、カスタムラベル（例: workflow::blocked）を使用してそれらを追跡できます。

事前に定義されたイベントに基づいて、バリューストリーム分析のステージをカスタマイズできます。設定を支援するために、GitLabはテンプレートとして使用できる事前に定義されたステージのリストを提供します。たとえば、イシューにラベルを追加したときに開始し、別のラベルを追加したときに終了するステージを定義できます。

次の表は、バリューストリーム分析における事前に定義されたステージの概要を示しています。

本番環境

バリューストリーム分析は、以下のいずれかのパターンに一致する名前を持つプロジェクトの本番環境を検索することで、環境を特定します:

• prodまたはprod/*
• productionまたはproduction/*

これらのパターンは大文字と小文字を区別しません。

プロジェクト環境の名前は、GitLab CI/CDの設定で変更できます。

例のワークフロー

この例は、1日で行われる7つのステージすべてのワークフローを示しています。

ステージに開始時刻と停止時刻が含まれていない場合、そのデータは中央値時間に含まれません。この例では、マイルストーンが作成され、テストおよび環境設定のためのCI/CDが設定されています。

• 09:00: イシューを作成します。Issueステージが開始します。
• 11:00: イシューをマイルストーン（またはバックログ）に追加し、イシューでの作業を開始し、ローカルでブランチを作成します。Issueステージが停止し、Planステージが開始します。
• 12:00: 最初のコミットを行います。
• 12:30: イシュー番号を記載したブランチに2番目のコミットを行います。Planステージが停止し、コードステージが開始します。
• 14:00: ブランチをプッシュし、イシュークローズパターンを含むマージリクエストを作成します。コードステージが停止し、TestステージとReviewステージが開始します。
• GitLab CI/CDは、.gitlab-ci.ymlファイルで定義されたスクリプトを実行するのに5分かかります。
• 19:00: マージリクエストをマージする。Reviewステージが停止し、ステージングステージが開始します。
• 19:30: production環境へのデプロイが完了します。ステージングが停止します。

バリューストリーム分析は、各ステージについて次の時間を記録します:

• Issue: 09:00から11:00: 2時間
• Plan: 11:00から12:00: 1時間
• コード: 12:00から14:00: 2時間
• Test: 5分
• Review: 14:00から19:00: 5時間
• ステージング: 19:00から19:30: 30分

この例に関連する次の点を考慮してください:

• この例は、最初のコミットがイシュー番号を記載していなくても問題ないことを示しています。これは、作業中のブランチ上のどのコミットでも後で行うことができます。
• Testステージは、サイクルの全体的な時間計算に使用されます。すべてのMRがテストされるべきであるため、それはReviewプロセスに含まれます。
• この例は、7つのステージのうち、one cycleのみを示しています。バリューストリーム分析ダッシュボードは、複数のサイクルの中央値時間を表示します。

累積ラベルイベント期間

この機能により、バリューストリーム分析は、ラベルベースのステージにおける反復イベントの期間を測定します。開始イベントと終了イベントの両方について、ラベルの削除または追加イベントを設定する必要があります。

例えば、ステージはin progressラベルが追加および削除された時刻を追跡します:

• 9:00: ラベルが追加されました。
• 10:00: ラベルが削除されました。
• 12:00: ラベルが追加されました。
• 14:00: ラベルが削除されました。

元の計算方法では、期間は5時間（9:00から14:00まで）です。累積ラベルイベント期間計算が有効な場合、期間は3時間（9:00から10:00および12:00から14:00）です。

カスタムバリューストリームのラベルベースのステージ

複雑なワークフローを測定するには、スコープ付きラベルを使用できます。たとえば、ステージング環境から本番環境へのデプロイ時間を測定するには、次のラベルを使用できます:

• コードがステージングにデプロイされると、workflow::stagingラベルがマージリクエストに追加されます。
• コードが本番環境にデプロイされると、workflow::productionラベルがマージリクエストに追加されます。

Webhookによる自動データラベル付け

GitLab Webhookイベントを使用すると、ラベルがマージリクエストまたはイシューに特定のイベント発生時に自動的に適用されるように、ラベルを自動的に追加できます。次に、ラベルベースのステージを追加してワークフローを追跡できます。実装の詳細については、ブログ記事Applying GitLab Labels Automaticallyを参照してください。

設定例

前の例では、Test Groupで異なる開発ワークフローを使用している2つのチームのために、2つの独立したバリューストリームが設定されています。

最初のバリューストリームは、ステージを定義するために標準のタイムスタンプベースのイベントを使用します。2番目のバリューストリームはラベルイベントを使用します。

データ集計

バリューストリーム分析は、バックエンドプロセスを使用してステージレベルのデータを収集および集計します。これにより、多数のイシューとマージリクエストを抱える大規模なグループでもスケールすることができます。このプロセスのため、アクションが実行されてから（例: イシューをクローズする）、バリューストリーム分析ページにデータが表示されるまでにわずかな遅延が生じる場合があります。

データの処理と結果の表示には最大10分かかる場合があります。次の場合、データ収集に10分以上かかる場合があります:

• バリューストリーム分析を初めて表示し、まだバリューストリームを作成していない場合。
• グループ階層が再編成された場合。
• イシューおよびマージリクエストで一括更新があった場合。

データが最後に更新された日時を表示するには、編集の横の右隅にある最終更新日バッジにカーソルを合わせます。

バリューストリーム分析の表示

前提条件:

• レポーター、デベロッパー、メンテナー、またはオーナーロールが必要です。
• カスタムバリューストリームを作成する必要があります。バリューストリーム分析は、グループまたはプロジェクト用に作成されたカスタムバリューストリームのみを表示します。

グループまたはプロジェクトのバリューストリーム分析を表示するには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトまたはグループを見つけます。
2. 左サイドバーで、分析 > バリューストリーム分析を選択します。
3. 特定のステージのメトリクスを表示するには、結果をフィルタリングテキストボックスの下にあるステージを選択します。
4. オプション。結果をフィルタリングします:

   1. 結果をフィルタリングテキストボックスを選択します。

   2. パラメータを選択します。

   3. 値を選択するか、テキストを入力して結果を絞り込みます。

   4. 特定の期間のメトリクスを表示するには、ドロップダウンリストから定義済みの期間、またはカスタムオプションを選択します。カスタムオプションが選択されている場合:

      • 開始日フィールドで、開始日を選択します。
      • 終了日フィールドで、終了日を選択します。

      チャートとリストには、期間中に作成された作業アイテムが表示されます。

5. オプション。結果を昇順または降順で並べ替えます:
   • 最新または最も古いワークフロー作業アイテムでソートするには、最後のイベントヘッダーを選択します。
   • 各ステージで費やされた時間の多い順または少ない順にソートするには、期間ヘッダーを選択します。

作業アイテムテーブルヘッダーの横にあるバッジは、選択したステージ中に完了した作業アイテムの数を示します。

この表は、選択したステージに関連する作業アイテムのリストを示しています。選択したステージに基づいて、これは次のいずれかになります:

• イシュー
• マージリクエスト

データフィルター

特定の条件に一致するデータを表示するために、バリューストリーム分析をフィルタリングできます。次のフィルターがサポートされています:

• 日付範囲
• プロジェクト
• 担当者
• Author
• マイルストーン
• ラベル

ライフサイクルとDORAメトリクスの表示

前提条件:

• デプロイメトリクスを表示するには、本番環境が設定されている必要があります。

ライフサイクルメトリクスを表示するには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトまたはグループを見つけます。
2. 左サイドバーで、分析 > バリューストリーム分析を選択します。ライフサイクルメトリクスが結果をフィルタリングテキストボックスの下に表示されます。
3. オプション。結果をフィルタリングします:
   1. 結果をフィルタリングテキストボックスを選択します。選択したフィルターに基づいて、ダッシュボードは自動的にライフサイクルメトリクスを集計し、バリューストリームのステータスを表示します。
   2. パラメータを選択します。
   3. 値を選択するか、テキストを入力して結果を絞り込みます。
   4. 期間を調整するには:
      • 開始日フィールドで、開始日を選択します。
      • 終了日フィールドで、終了日を選択します。

Value Streams DashboardとDORAメトリクスを表示するには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトまたはグループを見つけます。
2. 左サイドバーで、分析 > バリューストリーム分析を選択します。
3. 結果をフィルタリングテキストボックスの下にあるライフサイクルメトリクス行で、Value Streams Dashboard / DORAを選択します。
4. オプション。新しいページを開くには、グループURLにこのパス/analytics/dashboards/value_streams_dashboardを追加します（例: https://gitlab.com/groups/gitlab-org/-/analytics/dashboards/value_streams_dashboard）。

各開発ステージのメトリクスを表示

バリューストリーム分析は、各ソフトウェア開発ステージでイシューまたはマージリクエストに費やされた時間の中央値を表示します。

グループごとに各ステージで費やされた時間の中央値を表示するには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトまたはグループを見つけます。
2. 左サイドバーで、分析 > バリューストリーム分析を選択します。
3. オプション。結果をフィルタリングします:
   1. 結果をフィルタリングテキストボックスを選択します。
   2. パラメータを選択します。
   3. 値を選択するか、テキストを入力して結果を絞り込みます。
   4. 期間を調整するには:
      • 開始日フィールドで、開始日を選択します。
      • 終了日フィールドで、終了日を選択します。
4. 各ステージのメトリクスを表示するには、結果をフィルタリングテキストボックスの上でステージにカーソルを合わせます。

GraphQL APIを使用して、バリューストリーム分析データを取得することもできます。

タスクをタイプ別に表示

タイプ別のタスクチャートには、グループの1日あたりの完了したタスク（クローズされたイシューとマージされたマージリクエスト）の累積数が表示されます。

このチャートは、グローバルページフィルターを使用して、選択されたグループと期間に基づいたデータを表示します。

タイプ別にタスクを表示するには:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 左サイドバーで、分析 > バリューストリーム分析を選択します。
3. 結果をフィルタリングテキストボックスの下にある概要を選択します。タイプ別のタスクチャートは、合計時間チャートの下に表示されます。
4. オプション。タスクをタイプでフィルタリングするには、設定（ ）を選択し、次にイシューまたはマージリクエストを選択します。
5. オプション。タスクをラベルでフィルタリングするには、設定（ ）を選択し、次に1つ以上のラベルを選択します。デフォルトでは、上位のグループラベル（最大10個）が選択されます。最大15個のラベルを選択できます。

バリューストリームを作成する

デフォルトステージを使用

デフォルトステージを使用してバリューストリームを作成するには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトまたはグループを見つけます。
2. 左サイドバーで、分析 > Value Stream analyticsを選択します。
3. New Value Streamを選択します。
4. バリューストリームの名前を入力します。
5. デフォルトテンプレートから作成を選択します。
6. デフォルトステージをカスタマイズします:
   • ステージを並べ替えるには、上矢印または下矢印を選択します。
   • ステージを非表示にするには、非表示（ ）を選択します。
7. カスタムステージを追加するには、ステージを追加するを選択します。
   • ステージの名前を入力します。
   • 開始イベントとStop eventを選択します。
8. 新しいバリューストリームを選択します。

カスタムステージを使用

カスタムステージを使用してバリューストリームを作成するには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトまたはグループを見つけます。
2. 左サイドバーで、分析 > Value Stream analyticsを選択します。
3. 新しいバリューストリームを選択します。
4. 各ステージについて:
   • ステージの名前を入力します。
   • 開始イベントとStop eventを選択します。
5. 別のステージを追加するには、ステージを追加するを選択します。
6. ステージを並べ替えるには、上矢印または下矢印を選択します。
7. 新しいバリューストリームを選択します。

ビデオによる説明については、「Optimizing merge request review process with Value Stream Analytic」を参照してください。

バリューストリームを編集

バリューストリームを作成した後、目的に合わせてカスタマイズできます。バリューストリームを編集するには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトまたはグループを見つけます。
2. 左サイドバーで、分析 > バリューストリーム分析を選択します。
3. バリューストリームドロップダウンリストから、編集するバリューストリームを選択します。
4. バリューストリームドロップダウンリストの横にある編集を選択します。
5. オプション:
   • バリューストリームの名前を変更します。
   • デフォルトステージを非表示にするか、並べ替えます。
   • 既存のカスタムステージを削除します。
   • 新しいステージを追加するには、ステージを追加するを選択します。
   • ステージの開始イベントと終了イベントを選択します。
6. オプション。変更を元に戻すには、Restore value stream defaultsを選択します。
7. Save Value Streamを選択します。

バリューストリームを削除

カスタムバリューストリームを削除するには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトまたはグループを見つけます。
2. 左サイドバーで、分析 > バリューストリーム分析を選択します。
3. バリューストリームドロップダウンリストから、バリューストリームを削除するものを選択し、次に**Delete（name of value stream）**を選択します。
4. 確認するには、削除を選択します。

完了までのサイクル日数を見る

Total time chartは、開発サイクルが完了するまでにかかる平均日数を表示します。このチャートは、最後の500個の作業アイテムのデータを表示します。

1. 上部のバーで、検索または移動先を選択して、プロジェクトまたはグループを見つけます。
2. 左サイドバーで、分析 > バリューストリーム分析を選択します。
3. 結果をフィルタリングボックスの上にあるステージを選択します:
   • すべてのステージのサイクルタイムの概要を表示するには、概要を選択します。
   • 特定のステージのサイクルタイムを表示するには、ステージを選択します。
4. オプション。結果をフィルタリングします:
   1. 結果をフィルタリングテキストボックスを選択します。
   2. パラメータを選択します。
   3. 値を選択するか、テキストを入力して結果を絞り込みます。
   4. 期間を調整するには:
      • 開始日フィールドで、開始日を選択します。
      • 終了日フィールドで、終了日を選択します。

アップグレード後のデータの再集計

大規模なインスタンスでは、GitLabのバージョンをアップグレードする場合、特にいくつかのマイナーバージョンがスキップされると、バックグラウンドでの集計プロセスに時間がかかる場合があります。この遅延により、バリューストリーム分析ページでデータが古くなる可能性があります。集計プロセスを高速化し、古いデータを回避するには、Railsコンソールで特定のグループの同期集計スニペットを実行することができます:

group = Group.find(-1) # put your group id here
group_to_aggregate = group.root_ancestor

loop do
  cursor = {}
  context = Analytics::CycleAnalytics::AggregationContext.new(cursor: cursor)
  service_response = Analytics::CycleAnalytics::DataLoaderService.new(group: group_to_aggregate, model: Issue, context: context).execute

  if service_response.success? && service_response.payload[:reason] == :limit_reached
    cursor = service_response.payload[:context].cursor
  elsif service_response.success?
    puts "finished"
    break
  else
    puts "failed"
    break
  end
end

loop do
  cursor = {}
  context = Analytics::CycleAnalytics::AggregationContext.new(cursor: cursor)
  service_response = Analytics::CycleAnalytics::DataLoaderService.new(group: group_to_aggregate, model: MergeRequest, context: context).execute

  if service_response.success? && service_response.payload[:reason] == :limit_reached
    cursor = service_response.payload[:context].cursor
  elsif service_response.success?
    puts "finished"
    break
  else
    puts "failed"
    break
  end
end

アクセス権限

バリューストリーム分析のアクセス権限は、プロジェクトタイプによって異なります。

機能の可用性

バリューストリーム分析はプロジェクトとグループの機能を提供し、利用可能な機能はプランによって異なります。

• Freeプランでは、バリューストリーム分析はデータを集計しません。日付範囲フィルターがイシューとマージリクエストの作成日に適用されるデータベースを直接クエリします。事前定義されたデフォルトステージでバリューストリーム分析を表示できます。
• PremiumおよびUltimateプランでは、バリューストリーム分析はデータを集計し、終了イベントに日付範囲フィルターを適用します。バリューストリームの作成、編集、削除もできます。

トラブルシューティング

SidekiqによるCPU使用率100% cronjob:analytics_cycle_analytics

バリューストリーム分析のバックグラウンドジョブがCPUリソースを独占することでパフォーマンスに大きな影響を与える可能性があります。

この状況から復旧するには:

1. Railsコンソールで、すべてのプロジェクトの機能を無効にし、既存のジョブを削除します:

   Project.find_each do |p|
     p.analytics_access_level='disabled';
     p.save!
   end
   
   Analytics::CycleAnalytics::GroupStage.delete_all
   Analytics::CycleAnalytics::Aggregation.delete_all

2. 例えば、単一のfeature_category=value_stream_managementおよび複数のfeature_category!=value_stream_managementエントリを持つSidekiq routingを設定します。他の関連するキューメタデータは、Enterprise Edition listで確認できます。

3. バリューストリーム分析をプロジェクトごとに有効にします。パフォーマンス要件に応じて、Sidekiqルーティングをさらに微調整する必要がある場合があります。