価値ストリーム分析

バリューストリーム分析では、アイデアから生産までにかかる時間を測定します。

価値の流れとは、顧客に価値を提供する作業プロセス全体のことです。例えば、DevOpsライフサイクルは、「管理」ステージから始まり「保護」ステージで終わる価値の流れです。

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

  • アイデアから生産までにかかる時間。
  • プロジェクトの速度。
  • 開発プロセスのボトルネック。
  • 長期化しているイシューやマージリクエスト。
  • ソフトウェア開発ライフサイクルを遅らせる要因。

バリューストリームアナリティクスはビジネスを支援します:

  • エンドツーエンドのDevSecOpsワークストリームを可視化します。
  • 非効率の特定と解決
  • ワークストリームを最適化し、より早く、より多くの価値を提供します。

バリューストリーム・アナリティクスは、プロジェクトとグループで利用できます。

機能の可用性

バリューストリームアナリティクスは、FOSS版とライセンス版で、プロジェクトとグループレベルで異なる機能を提供します。

  • GitLab Freeでは、バリューストリーム分析はデータを集約しません。データベースに直接クエリし、イシューやマージリクエストの作成日に日付範囲フィルタが適用されます。事前に定義されたデフォルトステージでバリューストリーム分析を表示することができます。
  • GitLab Premiumでは、バリューストリーム分析はデータを集約し、終了イベントに日付範囲フィルタを適用します。バリューストリームを作成、編集、削除することもできます。
機能グループレベル (ライセンス)プロジェクトレベル (ライセンス)プロジェクトレベル(FOSS)---- カスタム・バリュー・ストリームの作成YesYesいいえ、バリュー・ストリーム (デフォルト) はデフォルト・ステージで1つだけ存在しますカスタム・ステージの作成YesYesいいえフィルタリング (作成者、ラベル、マイルストーンなど)、ステージタイムチャートYesYesNo合計時間チャートYesYesNoタイプ別タスクチャートYesNoNoDORAメトリクスYesYesNoサイクルタイムとリードタイムのサマリー(ライフサイクルメトリクス)YesYesNo新しいイシュー、コミット、デプロイ (ライフサイクル・メトリクス)Yes、コミットを除くYesYes集計されたバックエンドを使用YesYesNo日付フィルターの動作 日付の範囲内で終了したアイテムをフィルター[](https://gitlab.com/groups/gitlab-org/-/epics/6046)作成日でアイテムをフィルター作成日作成者少なくともレポーター少なくともレポーター公開可能
note
新しいレコードProjectNamespaceを使用することで、プロジェクトレベルとグループレベルのバリューストリーム分析のフィーチャーパリティが達成されます。この統合イニシアチブの詳細については、組織のドキュメントを参照してください。

価値ストリーム分析の仕組み

バリューストリーム分析では、ソフトウェア開発プロセスの各ステージの期間を計算します。

バリューストリームアナリティクスは、3つのCoreオブジェクトで構成されています:

  • バリューストリームには、バリューストリームのステージリストが含まれます。
  • 各値のストリームのステージ・リストには、1 つ以上のステージが含まれます。
  • 各ステージには、開始と停止の 2 つのイベントがあります。

価値の流れのステージ

ステージは、イベントペア(開始イベントと終了イベント)をステージ名などの追加メタデータとともに表します。ステージは、バックエンドで定義されたペアリング・ルールで設定できます。

値のストリーム

バリューストリームは、ステージのコンテナオブジェクトです。グループごとに複数のバリューストリームを持つことができ、DevOpsライフサイクルのさまざまな側面に焦点を当てることができます。

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

イベントは、バリューストリーム分析機能の最小構成要素です。ステージは開始イベントと終了イベントで構成されます。

以下のステージイベントがあります:

  • イシュー終了
  • イシューの作成
  • イシューが最初にボードに追加された日
  • 最初に割り当てられたイシュー
  • マイルストーンに最初に関連付けられたイシュー
  • 最初に言及されたイシュー
  • イシューラベル追加
  • イシューラベル削除
  • MRクローズ
  • MRマージ
  • MR作成
  • MR ファーストコミット時間
  • MRの最初の割り当て
  • MRの最初のデプロイ
  • MRラベル追加
  • MRラベル削除
  • MR 最終パイプライン期間

これらのイベントは、継続時間の計算において重要なロールを果たします。継続時間=イベント終了時間-イベント開始時間という式で計算されます。

どのような開始イベントと終了イベントがペアになるかは、開始イベントと終了イベントの検証を参照してください。

バリューストリーム・アナリティクスによるデータの集約方法

  • GitLab 14.5 で導入されました
  • GitLab 14.9で追加された停止日によるフィルタリングのトグル。
  • GitLab 14.9 でデータ更新バッジが追加されました。
  • GitLab 14.9で停止日によるフィルタリングのトグルが削除されました。
  • GitLab15.0で停止日によるフィルタリングを有効にしました

バリューストリーム分析では、ステージレベルのデータを収集・集計するためにバックエンドプロセスを使用します。これにより、イシューやマージリクエストの数が多い大規模なグループでも拡張できるようになっています。このプロセスのため、アクション(イシューのクローズなど)が発生してからバリューストリーム分析ページにデータが表示されるまでに若干の遅延が発生する場合があります。

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

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

最新の更新日時を表示するには、右隅の編集の横にある最終更新日時バッジにカーソルを合わせてください。

価値ストリーム分析によるステージの測定方法

バリューストリームアナリティクスでは、各ステージの開始イベントから終了イベントまでを測定します。

例えば、ステージはユーザーがイシューにラベルを追加したときに開始し、別のラベルを追加したときに終了します。アイテムが終了イベントに達していない場合は、ステージ時間の計算に含まれません。

バリューストリーム分析では、事前に定義したイベントに基づいてステージをカスタマイズできます。設定を簡単にするために、GitLabはテンプレートとして使えるステージの定義済みリストを提供します。

バリューストリームアナリティクスの定義済みの各ステージは、以下の表で詳しく説明します。

ステージ測定方法
イシューイシューを作成してから、そのイシューにラベルを付けるかマイルストーンに追加するか、どちらか先にアクションを起こすまでの時間の中央値です。ラベルは、すでにイシューボードリストが作成されている場合のみ追跡されます。
Plan前のステージでとったアクションから、最初のコミットをブランチにプッシュするまでの時間の中央値。ブランチの最初のコミットが、プランと コードの分離のトリガーとなります。ブランチのコミットのうち少なくともひとつには、関連するイシュー番号が含まれていなければなりません (たとえば#42)。ブランチ内のどのコミットにも関連イシュー番号が含まれていない場合、そのステージの測定時間には考慮されません。
コード最初のコミット (前のステージ) をプッシュしてから、そのコミットに関連するマージリクエスト(MR) を作成するまでの時間の中央値です。プロセスを追跡し続ける鍵は、マージリクエストの説明にイシューの終了パターンを含めることです。例えば、Closes #xxxxxx はこのマージリクエストに関連するイシューの番号です。終了パターンがない場合、マージリクエストの最初のコミットの作成時刻を開始時刻として計算します。
テストそのプロジェクトのパイプライン全体を実行する時間の中央値。GitLab CI/CD がマージリクエストにプッシュされたコミットに対してすべてのジョブを実行するのにかかる時間と関連しています。基本的に、すべてのパイプラインの開始-終了時間です。
レビュー終了イシューパターンを持つマージリクエストが作成されてからマージされるまでに、レビューにかかった時間の中央値です。
ステージングクローズするイシューパターンを持つマージリクエストをマージしてから、本番環境に最初にデプロイするまでの時間の中央値。本番環境がない場合は追跡されません。
note
バリューストリーム分析では、タイムスタンプデータを使用し、ステージの最終的な開始イベントと停止イベントのみを集計します。ステージ間を何度も行き来するイベントについては、ステージ時間は最終イベントのタイムスタンプのみから計算されます。

バリューストリーム解析による各ステージの計算方法については、バリューストリーム解析開発ガイドを参照してください。

ワークフロー例

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

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

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

バリューストリームアナリティクスでは、各ステージで以下の時間が記録されます:

  • イシュー:09:00~11:00:2時間
  • プラン11:00から12:00まで:1時間
  • コード12:00から14:00まで:2時間
  • テスト:5分
  • レビュー14:00~19:00:5時間
  • ステージ:19:00~19:30:30分

この例に関連する以下の観察に留意してください:

  • この例では、最初のコミットでイシュー番号に触れなくても問題ないことを示しています。
  • テストステージは、サイクル全体の時間の計算に使用されます。すべての MR をテストする必要があるため、レビュープロセスに含まれます。
  • この例では、7つのステージのうち1つのサイクルのみを示しています。バリューストリーム分析ダッシュボードには、複数のサイクルの中央値が表示されます。

価値ストリーム分析による生産環境の特定方法

バリューストリームアナリティクスは、これらのパターンのいずれかに一致する名前を持つプロジェクト環境を探すことで、生産環境を特定します:

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

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

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

価値のストリーム分析の表示

前提条件:

  • 少なくともレポーターロールを持っている必要があります。
  • カスタム・バリュー・ストリームを作成する必要があります。バリュー・ストリーム分析では、グループまたはプロジェクト用に作成されたカスタム・バリュー・ストリームのみが表示されます。

グループまたはプロジェクトのバリューストリーム分析を表示するには、以下の手順に従います:

  1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
  2. Analyze > Value stream analyticsを選択します。
  3. 特定のステージのメトリクスを表示するには、[Filter results]テキストボックスの下にあるステージを選択します。
  4. オプション。結果をフィルタリングします:
    1. フィルタ結果]テキストボックスを選択します。
    2. パラメータを選択します。
    3. 値を選択するか、テキストを入力して結果を絞り込みます。
    4. 日付範囲を調整するには
      • 開始日]フィールドで開始日を選択します。
      • To]フィールドで、終了日を選択します。チャートとリストには、日付範囲内に作成されたワークフロー項目が表示されます。
  5. オプション結果を昇順または降順でソートします:
    • 最も新しいまたは最も古いワークフロー項目でソートするには、Last eventheaderを選択します。
    • 各ステージに費やされた時間の多い順、少ない順に並べ替えるには、Durationヘッダを選択します。

ワークフロー項目テーブルのヘッダーの横にあるバッジは、選択したステージで完了したワークフロー項目の数を示します。

テーブルには、選択したステージに関連するワークフロー項目のリストが表示さ れます。選択したステージに応じて、以下のようになります:

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

データフィルター

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

  • 日付範囲
  • プロジェクト
  • Assignee
  • Author
  • Milestone
  • レーベル
note
タイプ別タスク」チャートでは、日付範囲とプロジェクトセレクタのフィルタのみが利用可能です。ラベルやその他のフィルターは適用されませんので、チャートの横にあるドロップダウンリストからラベルを別途選択する必要があります。

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

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

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

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

  • リードタイム:リードタイム:イシューが作成されてからクローズされるまでの時間の中央値。
  • サイクルタイム:最初のコミットからイシューがクローズされるまでの時間の中央値。GitLabは、リンクされたイシューのマージリクエストの一番最初のコミットから、そのイシューがクローズされるまでのサイクルタイムを測定します。マージリクエストの作成は常にコミット時間よりも遅くなるため、サイクルタイムのアプローチはリードタイムを過小評価します。
  • 新しいイシュー:新しく作成されたイシューの数。
  • デプロイ数:本番環境へのデプロイの総数。

DORAメトリクス

  • GitLab 14.5で変更のリードタイムDORAメトリクスを導入しました。
  • GitLab 14.3で、グループのバリューストリーム分析のためのDORA APIベースのデプロイメトリクスがGitLab UltimateからGitLab Premiumに移動しました。
  • GitLab 15.0でサービスタイルの復元時間を導入しました。
  • GitLab 15.0で変更失敗率タイルを導入

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

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

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

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

  • 成功したデプロイ回数はDORAデータで計算されます。
  • データは環境と環境階層に基づいてフィルタリングされます。
note
GitLab 13.9以降では、デプロイ頻度メトリクスはデプロイが完了したタイミングに基づいて計算されます。GitLab 13.8以前では、デプロイの頻度メトリクスはデプロイが作成されたタイミングに基づいて計算されます。

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

前提条件

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

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

バリュー・ストリーム・ダッシュボードと DORAメトリクスを表示します:

  1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
  2. Analyze > Value stream analyticsを選択します。
  3. Filter results]テキストボックスの下の[Lifecycle metrics]行で、[Value Streams Dashboard / DORA]を選択します。
  4. オプション。新しいページを開くには、このパス/analytics/dashboards/value_streams_dashboard をグループ URL に追加します(例:https://gitlab.com/groups/gitlab-org/-/analytics/dashboards/value_streams_dashboard)。

各開発ステージのメトリクスを表示します。

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

グループ別に各ステージに費やされた時間の中央値を表示します:

  1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
  2. Analyze > Value stream analyticsを選択します。
  3. オプション。結果をフィルタリングします:
    1. フィルタ結果]テキストボックスを選択します。
    2. パラメータを選択します。
    3. 値を選択するか、テキストを入力して結果を絞り込みます。
    4. 日付範囲を調整するには
      • 開始日]フィールドで開始日を選択します。
      • Toフィールドで、終了日を選択します。
  4. 各ステージのメトリクスを表示するには、[Filter results(結果の絞り込み)] テキスト・ボックスの上にあるステージにカーソルを合わせます。
note
日付範囲セレクタは、イベント時間で項目をフィルタリングします。イベント時刻は、選択したステージが指定したアイテムで終了した時刻です。

タスクをタイプ別に表示

タイプ別タスクチャートは、グループの1日あたりのイシューとマージリクエストの累積数を表示します。

Chartはグローバルページフィルタを使用して、選択したグループと時間枠に基づいてデータを表示します。

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

  1. 左のサイドバーで、Search(検索)を選択するか、Go to(移動)を選択してグループを探します。
  2. Analyze > Value stream analyticsを選択します。
  3. Filter results]テキストボックスの下にある[Overview]を選択します。合計時間] チャートの下に [タイプ別タスク] チャートが表示されます。
  4. タスクタイプを切り替えるには、設定({settings})ドロップダウンリストを選択し、イシューまたはマージリクエストを選択します。
  5. ラベルを追加または削除するには、設定({settings})ドロップダウンリストを選択し、ラベルを選択または検索します。デフォルトでは、一番上のグループレベルのラベル(最大10)が選択されています。ラベルは最大15個まで選択できます。

値のストリームの作成

GitLabのデフォルトステージを使ってバリューストリームを作成します。

GitLab 13.3で導入されました

バリューストリームを作成する際、GitLabのデフォルトステージを使用し、ステージを非表示にしたり並べ替えたりすることができます。また、デフォルトテンプレートで提供されているステージに加えて、カスタムステージを作成することもできます。

  1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
  2. Analyze > Value Stream analyticsを選択します。
  3. Create new Value Stream を選択します。
  4. バリューストリームの名前を入力します。
  5. デフォルトのテンプレートから作成]を選択します。
  6. デフォルトステージをカスタマイズします:
    • ステージを並べ替えるには、上下の矢印を選択します。
    • ステージを非表示にするには、Hide({eye-slash})を選択します。
  7. カスタムステージを追加するには、Add another stageを選択します。
    • ステージの名前を入力します。
    • 開始イベントと 停止イベントを選択します。
  8. 値のストリームを作成] を選択します。
note
GitLabプレミアムにアップグレードしたばかりの場合、データの収集と表示に最大30分かかることがあります。

カスタムステージでバリューストリームを作成

バリューストリームを作成する際に、独自の開発ワークフローに沿ったカスタムステージを作成・追加することができます。

  1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
  2. Analyze > Value Stream analyticsを選択します。
  3. 値のストリームを作成] を選択します。
  4. 各ステージで
    • ステージの名前を入力します。
    • 開始イベントと 停止イベントを選択します。
  5. 別のステージを追加するには、Add another stageを選択します。
  6. ステージを並べ替えるには、上下の矢印を選択します。
  7. 値のストリームを作成] を選択します。

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

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

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

Label-based value stream analytics stage

カスタム価値ストリーム設定の例

Example configuration

上記の例では、Test Group(最上位の名前空間)で異なる開発ワークフローを使用している 2 つのチームに対して、2 つの独立した価値の流れが設定されています。

最初の値ストリームでは、ステージの定義に標準的なタイムスタンプ・ベースのイベントを使用します。2 番目の値ストリームでは、ラベル・イベントを使用します。

値のストリームの編集

GitLab 13.10で導入されました

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

  1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
  2. Analyze > Value Stream analyticsを選択します。
  3. 右上のドロップダウンリストを選択し、バリューストリームを選択します。
  4. バリュー・ストリームのドロップダウン・リストの横で、[Edit] を選択します。
  5. オプション
    • 値のストリームの名前を変更します。
    • デフォルトステージの非表示または順序の変更。
    • 既存のカスタムステージの削除。
    • 新しいステージを追加するには、Add another stageを選択します。
    • ステージの開始イベントと終了イベントを選択します。
  6. オプション。変更した内容を元に戻すには、[値のストリームをデフォルトに戻す]を選択します。
  7. 値ストリームを保存]を選択します。

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

GitLab 13.4 で導入されました

カスタム値ストリームを削除するには

  1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
  2. 右上隅でドロップダウンリストを選択し、削除するバリューストリームを選択します。
  3. 削除(バリュー・ストリームの名前)]を選択します。
  4. 確認するには、Delete を選択します。

Delete value stream

サイクル完了までの日数の表示

合計時間チャートは、開発サイクルが完了するまでの平均日数を示しています。Chartは直近500件のワークフロー項目のデータを表示しています。

  1. 左側のサイドバーで、「検索」を選択するか、または「移動」を選択して、プロジェクトまたはグループを見つけます。
  2. Analyze > Value stream analyticsを選択します。
  3. Filter results]ボックスの上で、ステージを選択します:
    • 全ステージのサイクルタイムの概要を表示するには、Overview(概要)を選択します。
    • 特定のステージのサイクルタイムを表示するには、ステージを選択します。
  4. オプション。結果をフィルタリングします:
    1. フィルタ結果]テキストボックスを選択します。
    2. パラメータを選択します。
    3. 値を選択するか、テキストを入力して結果を絞り込みます。
    4. 日付範囲を調整するには
      • 開始日]フィールドで開始日を選択します。
      • Toフィールドで、終了日を選択します。

価値のストリーム分析のアクセス権限

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

プロジェクトタイプ権限
公開誰でもアクセスできます。
内部認証されたユーザーなら誰でもアクセスできます。
非公開ゲスト以上のメンバーなら誰でもアクセスできます。

トラブルシューティング

Sidekiqによる100%のCPU使用率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. Sidekiqルーティングを、例えば単一のfeature_category=value_stream_management 、複数のfeature_category!=value_stream_management エントリで設定します。Enterprise Editionのリストで他の関連キューメタデータを検索します。
  3. バリューストリーム分析をプロジェクトごとに有効化します。パフォーマンス要件に応じて、Sidekiqルーティングをさらに微調整する必要があるかもしれません。