バリューストリーム分析

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

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

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

バリューストリーム分析は、ビジネスの以下の点に役立ちます:

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

クリック操作で確認できるデモについては、バリューストリーム管理の製品ツアーをご覧ください。

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

• ひとつのvalue streamは、バリューストリームステージリストを含みます。
• 各バリューストリームステージリストは、1つ以上のstagesを含みます。
• 各ステージは、2つのeventsによって定義されます。

バリューストリーム

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

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

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

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

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

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

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

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

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

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

データ集計

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

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

• 初めてバリューストリーム分析を表示しており、まだバリューストリームを作成していない場合。
• グループの階層が再配置された場合。
• イシューやマージリクエストに対して一括更新が行われた場合。

データが最後に更新された日時を確認するには、編集の横にある右隅で、最終更新日バッジにカーソルを合わせてください。

ステージの測定

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

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

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

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

ワークフローの例

この例は、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ステージが停止し、Stagingステージステージが開始されます。
• 19:30: production環境へのデプロイが完了します。Stagingステージが停止します。

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

• 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時間
• Stagingステージ: 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）です。

アップグレード後にデータを再集計する

大規模なインスタンスでは、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

本番環境

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

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

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

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

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

前提条件:

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

グループまたはプロジェクトのバリューストリーム分析を表示するには、次の手順を実行します:

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

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

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

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

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

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

      チャートとリストには、指定された日付範囲内に作成された作業アイテムが表示されます。

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

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

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

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

データフィルター

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

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

バリューストリーム分析メトリクス

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

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

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

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

DORAメトリクス

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

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

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

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

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

ライフサイクルおよびDORAメトリクスの表示

前提条件:

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

ライフサイクルメトリクスを表示するには、次の手順を実行します:

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

バリューストリームダッシュボードとDORAメトリクスを表示するには、次の手順を実行します:

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

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

バリューストリーム分析は、各開発ステージでイシューまたはマージリクエストが費やした中央値時間を表示します。

グループが各ステージで費やした中央値時間を表示するには、次の手順を実行します:

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

タイプ別のタスクを表示

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

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

タイプ別のタスクを表示するには、次の手順を実行します:

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

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

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

デフォルトステージを持つバリューストリームを作成するには、次の手順を実行します:

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

カスタムステージを使用する

カスタムステージを持つバリューストリームを作成するには、次の手順を実行します:

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

ビデオ解説については、マージリクエストのレビュープロセスをバリューストリーム分析で最適化するをご覧ください。

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

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

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

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

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

設定例

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

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

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

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

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. 日付範囲を調整するには、次の手順を実行します:
      • Fromフィールドで開始日を選択します。
      • Toフィールドで終了日を選択します。

アクセス権限

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

VSA GraphQL API

VSA GraphQL APIを使用すると、設定されたバリューストリームおよびバリューストリームステージからメトリクスをリクエストできます。これは、VSAデータを外部システムにエクスポートする場合や、レポートを作成する場合に役立ちます。

次のメトリクスを利用できます。

• ステージで完了したアイテムの数。カウントは最大10,000アイテムに制限されています。
• ステージで完了したアイテムの中央値期間。
• ステージで完了したアイテムの平均期間。

メトリクスをリクエストする

前提条件:

• レポーター、デベロッパー、メンテナー、またはオーナーのいずれかのロールを持っている必要があります。

まず、レポートに使用するバリューストリームを決定する必要があります。

グループの設定済みバリューストリームをリクエストするには、以下を実行します:

group(fullPath: "your-group-path") {
  valueStreams {
    nodes {
      id
      name
    }
  }
}

同様に、プロジェクトのメトリクスをリクエストするには、以下を実行します:

project(fullPath: "your-project-path") {
  valueStreams {
    nodes {
      id
      name
    }
  }
}

バリューストリームのステージのメトリクスをリクエストするには、以下を実行します:

group(fullPath: "your-group-path") {
  valueStreams(id: "your-value-stream-id") {
    nodes {
      stages {
        id
        name
      }
    }
  }
}

データの使用方法に応じて、特定の1つのステージまたはバリューストリーム内のすべてのステージのメトリクスをリクエストできます。

ステージのメトリクスをリクエストする:

group(fullPath: "your-group-path") {
  valueStreams(id: "your-value-stream-id") {
    nodes {
      stages(id: "your-stage-id") {
        id
        name
        metrics(timeframe: { start: "2024-03-01", end: "2024-03-31" }) {
          average {
            value
            unit
          }
          median {
            value
            unit
          }
          count {
            value
            unit
          }
        }
      }
    }
  }
}

metricsノードは、追加のフィルタリングオプションをサポートしています:

• 担当者のユーザー名
• 作成者のユーザー名
• ラベル名
• マイルストーンのタイトル

フィルター付きリクエストの例:

group(fullPath: "your-group-path") {
  valueStreams(id: "your-value-stream-id") {
    nodes {
      stages(id: "your-stage-id") {
        id
        name
        metrics(
          labelNames: ["backend"],
          milestoneTitle: "17.0",
          timeframe: { start: "2024-03-01", end: "2024-03-31" }
        ) {
          average {
            value
            unit
          }
          median {
            value
            unit
          }
          count {
            value
            unit
          }
        }
      }
    }
  }
}

ベストプラクティス

• 現在のステータスを正確に把握するには、期間の終了にできるだけ近いタイミングでメトリクスをリクエストします。
• 定期的なレポート作成の場合、スクリプトを作成し、スケジュールされたパイプライン機能を使用して、データをタイムリーにエクスポートすることができます。
• APIを実行すると、データベースから現在のデータが取得されます。時間の経過とともに、データベースの基になるデータの変更により、同じメトリクスが変更される可能性があります。たとえば、グループからプロジェクトを移動または削除すると、グループレベルのメトリクスに影響を与える可能性があります。
• 以前の期間のメトリクスを再リクエストし、以前に収集されたメトリクスと比較することで、データの偏りを示すことができ、変化する傾向を発見し説明するのに役立ちます。

機能の可用性

バリューストリーム分析は、FOSSおよびライセンスバージョンのプロジェクトレベルとグループレベルで異なる機能を提供します。

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

トラブルシューティング

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ルーティングを設定します。その他の関連するキューメタデータは、Enterprise Editionリストで確認できます。

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