Analytics の履歴データ表現
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
履歴データをレポートする特定のエンティティ セットを指定するか、傾向レポートを作成します。 分析で履歴データを記録する方法を理解することは、目的のデータを確実に追跡および報告できるようにするために重要です。
履歴レポートをサポートするエンティティ セット
次の表では、履歴レポートまたは傾向レポートの作成に使用できるエンティティ セットについて説明します。
EntitySet |
説明 | サンプル レポート |
---|---|---|
WorkItemBoardSnapshot | (複合)ボードの場所を含む、各カレンダー日付の各作業項目の状態。 | 累積フロー図 (CFD) サンプル レポート |
WorkItemRevisions | 現在のリビジョンを含むすべての履歴作業項目のリビジョン。 削除された作業項目は含まれません。 | 特定の作業項目の履歴を返す |
WorkItemSnapshot | (複合)各カレンダー日付の各作業項目の状態。 | バグ傾向のサンプル レポート |
ParallelPipelineJobsSnapshot | (複合)並列パイプラインの使用の理解をサポートします。 | |
TaskAgentPoolSizeSnapshots | (複合)プール サイズ、パイプライン ジョブ、コンカレンシーの理解をサポートします。 | エージェント プールの履歴グラフ |
TaskAgentRequestSnapshots | (複合)タスク エージェント要求に関するレポートをサポートします。 | |
TestPointHistorySnapshot | (複合)TestRun に関連付けられている特定のテストの個々の実行結果。 | 手動テスト実行の傾向のサンプル レポート |
TestResultsDaily | Test でグループ化された TestResult 実行の毎日のスナップショット集計。 | テストの概要の傾向のサンプル レポート |
スナップショットは、エンティティ型に対して毎日定義されている値のレコードを提供します。 このレコードは、毎日同時に 1 日に 1 回 Analytics に書き込まれます。 傾向レポートを生成する場合は、スナップショットを使用します。 既定では、すべてのスナップショットテーブルは、毎日のスナップショットファクト テーブルとしてモデル化されます。 時間範囲のクエリを実行すると、各日の値が取得されます。 時間範囲が長い場合、多数のレコードが生成されます。 このような高精度が必要ない場合は、毎週または毎月のスナップショットを使用できます。
定期的なスナップショットファクト テーブル
分析では、履歴データが定期的なスナップショットファクト テーブルとしてモデル化されます。 ファクト テーブルには、各期間の最後に作業項目またはエンティティの種類ごとに午前 0 時に作成された 1 つの行が含まれています。 たとえば、日単位の期間の履歴は、各日の午前 0 時に 1 行としてモデル化され、週単位の期間は週の最終日の午前 0 時に 1 行になります。 週が完了していない場合、その週のスナップショット値は現在の値に基づいています。
このテーブルの粒度は、個々の作業項目ではなく期間です。 これは、履歴期間ごとに 1 つの作業項目が複数回表示されることを意味します。 過去 30 日間の履歴を選択すると、1 つの作業項目がデータ モデルに 30 回表示されます。 過去 30 日以内に作業項目が変更されていない場合、作業項目の最新のリビジョンは毎日レプリケートされます。
Power BI Data Connector と履歴データを使用する場合は、 フィールドを Date
使用することをお勧めします。 データセットに履歴データが含まれているが、現在の値のみが必要な場合は、 をIs Current
フィルター処理して設定できます。
たとえば、関連付けられたフィールドの作業項目と値のテーブルを表示する場合は、フィルターとして使用 Is Current
し、True に設定 します。 代わりに、状態に基づいて作業項目の傾向を表示する場合は、視覚化の軸に [日付 ] 列を含めます。
ヒント
[日付] 列を使用する場合は、常に [日付] オプションを使用します。 [日付] フィールドは、Power BI の既定の階層をサポートするためのものではありません。
作業項目のリビジョン
作業項目を更新するたびに、新しいリビジョンが作成され、このアクションが System.RevisedDate
フィールドに記録されるため、履歴フィルターを指定するのに役立ちます。 変更された日付は、(DateTime) プロパティと RevisedDateSK
(Int32) プロパティでRevisedDate
表されます。 最適なパフォーマンスを得るには、後者の日付サロゲート キーを使用します。 これは、リビジョンが作成された日付、またはアクティブまたは不完全なリビジョンに対して null を持つ日付を表します。
以降のすべての日付が必要な場合は {startDate}
、クエリに次のフィルターを追加します。
RevisedDateSK eq null or RevisedDateSK gt {startDateSK}
エンティティ セットを WorkItemRevisions
使用して、特定の作業項目のすべてのリビジョンを読み込みます。 クエリは、フィルター処理する作業項目に対して、現在のリビジョンを含むすべての履歴作業項目のリビジョンを返します。 削除された作業項目は含まれません。
ヒント
作業追跡傾向レポートを作成するには、既定の Analytics ビューを作成または変更しHistory タブで目的の期間を指定します。詳細については、「 Analytics ビューの作成」を参照してください。
Analytics ビューと Burndown ウィジェットと Burnup ウィジェットの両方を使用すると、データ セットをニーズに合わせてスコープ指定するフィルターを構成できます。 フィルターを適用して、特定のチーム、作業項目の種類、またはバックログにデータのスコープを設定します。 フィルターは、特定のプロパティまたはフィールドとそれに対応する値にも適用できます。 たとえば、作業項目にフィルターを適用して、 Fabrikam Voice チームに対して定義され、 Customer でタグ付けされたバグのみを返すことができます。
履歴データにフィルターを適用する方法
フィルターは、作業項目の各リビジョンに適用されます。 たとえば、次のリビジョンを含む作業項目があるとします。
牧師# | リビジョン日 | ID | タイトル | State | 区分パス | Tags |
---|---|---|---|---|---|---|
1 | Jan-01 | 1001 | バグ | 新規 | ||
2 | Jan-02 | 1001 | バグ | 新規 | /アドミラルズ | |
3 | Jan-10 | 1001 | バグ | アクティブ | /アドミラルズ | |
4 | Jan-12 | 1001 | バグ | アクティブ | /アドミラルズ | Customer |
5 | 1 月 20 日 | 1001 | バグ | 解決済み | /アドミラルズ | Customer |
6 (現在) | Jan-28 | 1001 | バグ | Closed | /アドミラルズ | Customer |
最新のリビジョン (#6) は、作業項目の現在のリビジョンです。 分析ビューで、[履歴] タブで [現在のみ] を選択した場合、この作業項目のデータ行 (現在の行) が 1 行表示されます。
履歴に関するレポートでは、レポートのためにリビジョン 1 から 6 をプルする可能性があります。
たとえば、Analytics ビューを作成するとき、またはバーンダウン ウィジェットを構成するときに、次の 2 つのフィルターを設定します。
- エリア パス = /アドミラル
- タグに Customer が含まれている
これらのフィルターを作業項目のリビジョンのセットに適用すると、次の一致が生成されます。
一致。 | 牧師# | リビジョン日 | ID | タイトル | State | 区分パス | Tags |
---|---|---|---|---|---|---|---|
1 | Jan-01 | 1001 | バグ | 新規 | |||
2 | Jan-02 | 1001 | バグ | 新規 | /アドミラルズ | ||
3 | Jan-10 | 1001 | バグ | アクティブ | /アドミラルズ | ||
4 | Jan-12 | 1001 | バグ | アクティブ | /アドミラルズ | Customer | |
5 | 1 月 20 日 | 1001 | バグ | 解決済み | /アドミラルズ | Customer | |
6 (現在) | Jan-28 | 1001 | バグ | Closed | /アドミラルズ | Customer |
リビジョン 1、2、3 は一致しません。これらのリビジョンがフィルターと一致しなかったためです。 上記の作業項目は、リビジョン 4 または 1 月 12 日までは、データ セットまたは傾向グラフに表示されません。
たとえば、アクティブなバグの傾向を報告したい場合は、State = Active のフィルターを作成します。 これらのフィルターは、次のリビジョンと一致します。
一致。 | 牧師# | Changed Date (変更日) | ID | タイトル | State | 区分パス | Tags |
---|---|---|---|---|---|---|---|
1 | Jan-01 | 1001 | バグ | 新規 | |||
2 | Jan-02 | 1001 | バグ | 新規 | /アドミラルズ | ||
3 | Jan-10 | 1001 | バグ | アクティブ | /アドミラルズ | ||
4 | Jan-12 | 1001 | バグ | アクティブ | /アドミラルズ | Customer | |
5 | 1 月 20 日 | 1001 | バグ | 解決済み | /アドミラルズ | Customer | |
6 (現在) | Jan-28 | 1001 | バグ | Closed | /アドミラルズ | Customer |
フィルターは作業項目のリビジョン 3 と 4 にのみ一致し、傾向グラフには 1 月 10 日と 1 月 12 日のリビジョンのみが含まれます。
バーンダウンまたはバーンアップの場合、これは何を意味しますか?
特定の タグ ("Customer" など) をフィルター処理するバーンダウンまたはバーンアップ ウィジェットを構成すると、作業項目に 対してタグ が定義されるまで、作業項目はバーンダウンに表示されません。 ある時点で タグ が作業項目から削除された場合、作業項目は 、タグ が削除された日付の後のバーンダウンから取得されます。
一部のユーザーは、作業項目の現在のバージョンに Tag がある場合、最初からさかのぼってバーンダウンに含まれると想定しています。 たとえば、現在のバージョンの作業項目に "Customer" というタグがある場合、作業項目が作成された時点からのバーンダウンに作業項目が含まれると想定されていました。
履歴フィルター処理の仕組みではありません。 フィルターが現在のバージョンの作業項目のみに基づいて適用された場合、傾向グラフは機能しません。 バーンダウンからアイテムを削除するには、タグを削除するか、エリア パスを別のチームのエリア パスに設定します。
Note
分析ビューとウィジェット (バーンダウン/バーンアップなど) のフィルター条件に "was ever" オペランドを追加することを検討しています。 この機能を使用すると、"State Was Ever Active" のようなフィルターを作成できます。 これは、作業項目のリビジョンが State = Active の場合、作業項目のリビジョンがフィルター条件と一致することを意味します。 この機能が重要であると思われる場合は、Developer Community サイトで投票できます。
履歴データと Analytics の一時停止または無効化
Analytics を一時停止すると、データは保持されますが、ステージング ジョブによるデータの更新は停止されます。 後でサービスを再開すると、データが更新されます。
管理者が Analytics を無効にすると、すべての Analytics ステージング ジョブが無効になり、Analytics テーブルに格納されている Analytics データが削除されます。 過去の傾向をキャプチャするすべての分析データが失われます。 コレクションに格納されている他のデータは削除されません。 この操作を元に戻すことはできません。 履歴データとトレンド データが削除されると、復元することはできません。 Analytics を再度有効にしても、履歴データは復元されません。
分析を無効または削除すると、次のアクションが発生します。
- ステージング ジョブは実行されません。また、Analytics テーブルには更新された情報はありません。
- テーブル データは削除され、Analytics が再び有効になっている場合は、すべてのデータが最初から再入力されます。
詳細については、「 Analytics サービスのインストールまたは有効化を参照してください。
まとめ
つまり、履歴データをレポートするときに、すべてのフィルターが、過去の時点の作業項目のバージョンに適用されます。 作業項目がフィルター条件を満たすと、傾向に表示されます。 フィルター条件を満たさなくなった場合、傾向から消えます。