バリューストリーム分析

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

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

• アイデアから本番環境までの時間。
• 特定のプロジェクトの開発速度。
• ソフトウェア開発プロセスにおけるボトルネック。
• 長期にわたるイシューまたはマージリクエスト。
• ソフトウェア開発ライフサイクルを遅らせる要因。

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

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

クリック操作のデモについては、Value Stream Managementの製品ツアーをご覧ください。

バリューストリーム分析には、階層構造があります:

• 1つのvalue stream（バリューストリーム） には、バリューストリームステージリストが含まれています。
• 各バリューストリームステージリストには、1つ以上のstages（ステージ）が含まれています。
• 各ステージは、開始と終了の2つのevents（イベント）によって定義されます。

バリューストリーム

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

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

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

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

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

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

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

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

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

ステージイベントに関するアイデアやフィードバックをissue 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: ブランチをプッシュし、イシューのクローズパターンを含むマージリクエストを作成します。コードステージが停止し、テストと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時間
• テスト: 5分
• Review: 14:00～19:00: 5時間
• Stagingステージ: 19:00～19:30: 30分

この例に関連する次の点に注意してください:

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

ラベルイベントの累積期間

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

たとえば、ステージは、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. 結果をフィルタリングテキストボックスの下のライフサイクルメトリクス行で、Value Streams Dashboard / DORA（バリューストリームダッシュボード / 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. 分析 > 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. 新しいバリューストリームを選択します。

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

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

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

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

Webhookを使用した自動データラベリング

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

設定例

前の例では、2つの独立したバリューストリームが、Test Group（トップレベルネームスペース）で異なる開発ワークフローを使用している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フィールドで終了日を選択します。

アクセス許可

バリューストリーム分析のアクセス許可は、プロジェクトの種類によって異なります。

バリューストリーム分析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
      }
    }
  }
}

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

ステージのメトリクスのリクエスト:

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. 1つのプロジェクトずつバリューストリーム分析を有効にします。パフォーマンス要件に応じて、Sidekiqルーティングをさらに微調整する必要がある場合があります。