Представление исторических данных в Аналитике
Azure DevOps Services | Azure DevOps Server 2022 г. - Azure DevOps Server 2019 г.
Вы указываете определенные наборы сущностей для создания отчетов об исторических данных или для создания отчетов о тенденциях. Понимание того, как аналитика записывает исторические данные, важно, чтобы вы могли отслеживать и сообщать интересующие вас данные.
Наборы сущностей, поддерживающие исторические отчеты
В следующей таблице описаны наборы сущностей, которые можно использовать для создания исторических отчетов или отчетов о тенденциях.
EntitySet |
Описание | Пример отчета |
|---|---|---|
| WorkItemBoardSnapshot | (Составной) Состояние каждого рабочего элемента на каждую дату календаря, включая расположение канбан-доски. | Пример отчета о совокупной схеме потоков (CFD) |
| WorkItemRevisions | Все исторические редакции рабочих элементов, включая текущую редакцию. Не включает удаленные рабочие элементы. | Возврат журнала определенного рабочего элемента |
| WorkItemSnapshot | (Составной) Состояние каждого рабочего элемента на каждую дату календаря. | Пример отчета о тенденциях ошибок |
| ParallelPipelineJobsSnapshot | (Составной) Поддерживает понимание использования параллельных конвейеров. | |
| TaskAgentPoolSizeSnapshots | (Составной) Поддерживает понимание размера пула, заданий конвейера и параллелизма. | Исторический граф для пулов агентов |
| TaskAgentRequestSnapshots | (Составной) Поддерживает отчеты о запросах агента задач. | |
| TestPointHistorySnapshot | (Составной) Отдельные результаты выполнения для определенного теста , связанного с TestRun. | Пример отчета о тенденциях выполнения тестов вручную |
| TestResultsDaily | Ежедневное snapshot агрегирование выполнений TestResult, сгруппированное по test. | Пример отчета о сводных тенденциях теста |
Snapshot предоставляет запись значений, определенных для типа сущности каждый день. Запись записывается в аналитику один раз в день в одно и то же время каждый день. Моментальные снимки используются для создания отчета о тенденциях. По умолчанию все таблицы snapshot смоделированы как ежедневные snapshot таблицы фактов. При запросе диапазона времени он получит значение для каждого дня. Длинные диапазоны времени приводят к большому количеству записей. Если такая высокая точность не требуется, можно использовать еженедельные или даже ежемесячные моментальные снимки.
Периодические snapshot таблицы фактов
Аналитика моделирует исторические данные как периодические snapshot таблицу фактов. Таблица фактов содержит одну строку, созданную в полночь для каждого рабочего элемента или типа сущности в конце каждого периода. Например, журнал ежедневного периода смоделирован как одна строка в полночь для каждого дня, а еженедельный период — одна строка в полночь последнего дня недели. Если неделя не завершена, snapshot значение недели основано на текущем значении.
Элементом этой таблицы является точка, а не отдельный рабочий элемент. Это означает, что один рабочий элемент будет отображаться несколько раз, по одному за каждый исторический период. При выборе журнала за последние 30 дней один рабочий элемент будет отображаться в модели данных 30 раз. Если рабочий элемент не изменялся в течение последних 30 дней, последняя редакция рабочего элемента реплицируется каждый день.
При работе с соединителем данных Power BI и историческими данными Date рекомендуется использовать поле . Если набор данных содержит исторические данные, но требуются только текущие значения, это можно настроить, отфильтровав Is Current.
Например, если вы хотите отобразить таблицу рабочих элементов и значений для связанных полей, следует использовать Is Current в качестве фильтра, для которого задано значение True. Если вы хотите отобразить тенденцию рабочих элементов на основе состояния, необходимо включить столбец Дата на оси визуализации.
Совет
Всегда используйте параметр Date при использовании столбца Date. Поле Date не предназначено для поддержки иерархий по умолчанию в Power BI.
Редакции рабочих элементов
При каждом обновлении рабочего элемента система создает новую редакцию и записывает это действие в System.RevisedDate поле, что делает его полезным для указания фильтра журнала. Измененная дата представлена свойствами RevisedDate (DateTime) и RevisedDateSK (Int32). Для оптимальной производительности используйте последний суррогатный ключ даты. Он представляет дату создания редакции или имеет значение NULL для активных или неполных редакций.
Если вам нужны все даты, начиная с {startDate} включительно, добавьте в запрос следующий фильтр.
RevisedDateSK eq null or RevisedDateSK gt {startDateSK}
Набор сущностей WorkItemRevisions используется для загрузки всех редакций для данного рабочего элемента. Запрос возвращает все исторические редакции рабочих элементов, включая текущую редакцию, для рабочих элементов, по которых выполняется фильтрация. Он не включает удаленные рабочие элементы.
Совет
Чтобы создать отчет о тенденциях отслеживания работы, создайте или измените представление аналитики по умолчанию и укажите интересующий период времени на вкладке Журнал . Дополнительные сведения см. в статье Создание представления аналитики.
Представления аналитики и мини-приложения Burndown и Burnup позволяют настроить фильтры, которые область набор данных в соответствии с вашими потребностями. Фильтры применяются для область данных к определенным командам, типам рабочих элементов или невыполненной работе. Фильтры также могут применяться к определенным свойствам или полям и их соответствующим значениям. Например, можно применить фильтры к рабочим элементам, чтобы возвращать только ошибки, определенные для команды Fabrikam Voice и помеченные как Customer.
Применение фильтров к историческим данным
Фильтры применяются к каждой редакции рабочего элемента. Например, предположим, что у нас есть рабочий элемент со следующими редакциями:
| Rev # | Дата редакции | ID | Название | Состояние | Путь к области | Теги |
|---|---|---|---|---|---|---|
| 1 | 1 января | 1001 | Ошибка | Создать | ||
| 2 | 2 января | 1001 | Ошибка | Создать | /Адмиралс | |
| 3 | 10 января | 1001 | Ошибка | Активен | /Адмиралс | |
| 4 | 12 января | 1001 | Ошибка | Активен | /Адмиралс | Customer |
| 5 | 20 января | 1001 | Ошибка | "Разрешено" | /Адмиралс | Customer |
| 6 (текущий) | 28 января | 1001 | Ошибка | Закрыто | /Адмиралс | Customer |
Последняя редакция (No 6) — текущая редакция рабочего элемента. Если в представлениях аналитики на вкладке Журнал выбран параметр "Только текущая", вы получите одну строку данных для этого рабочего элемента— текущую строку.
При составлении отчетов об истории мы потенциально можем извлекать редакции с 1 по 6 для отчетности.
Предположим, при создании представления аналитики или настройке мини-приложения Burndown задаются следующие два фильтра:
- Путь к области = /Адмиралы
- Теги содержат customer
Применение этих фильтров к набору исправлений рабочих элементов приводит к следующим совпадениям:
| Матч? | Rev # | Дата редакции | ID | Название | Состояние | Путь к области | Теги |
|---|---|---|---|---|---|---|---|
 |
1 | Январь-01 | 1001 | Ошибка | Создать | ||
|
2 | Январь-02 | 1001 | Ошибка | Создать | /Адмиралс | |
|
3 | 10 января | 1001 | Ошибка | Активен | /Адмиралс | |
 |
4 | 12 января | 1001 | Ошибка | Активен | /Адмиралс | Customer |
|
5 | 20 января | 1001 | Ошибка | "Разрешено" | /Адмиралс | Customer |
|
6 (текущий) | 28 января | 1001 | Ошибка | Закрыто | /Адмиралс | Customer |
Редакции 1, 2 и 3 не совпадают, так как эти редакции не соответствуют фильтрам. Указанный выше рабочий элемент не будет отображаться в наборе данных или диаграмме трендов до редакции 4 или до 12 января.
Предположим, что вы хотите сообщить о тенденции активных ошибок, создав фильтр Состояния = Активный. Эти фильтры будут соответствовать следующим редакциям:
| Матч? | Rev # | Дата изменения | ID | Название | Состояние | Путь к области | Теги |
|---|---|---|---|---|---|---|---|
|
1 | Январь-01 | 1001 | Ошибка | Создать | ||
|
2 | Январь-02 | 1001 | Ошибка | Создать | /Адмиралс | |
|
3 | 10 января | 1001 | Ошибка | Активен | /Адмиралс | |
|
4 | 12 января | 1001 | Ошибка | Активен | /Адмиралс | Customer |
|
5 | 20 января | 1001 | Ошибка | "Разрешено" | /Адмиралс | Customer |
|
6 (текущий) | 28 января | 1001 | Ошибка | Закрыто | /Адмиралс | Customer |
Фильтры будут соответствовать только редакции 3 и 4 рабочего элемента и будут включать в диаграмму тренда только редакции от 10 января и 12 января.
Что это означает для burndown или burnup?
При настройке мини-приложения Burndown или Burnup, которое фильтрует по заданному тегу (например, "Клиент"), рабочие элементы не будут отображаться при сгорании до даты определения тега для рабочего элемента. Если в какой-либо момент тег удаляется из рабочего элемента, рабочий элемент находится в состоянии сгорания после даты удаления тега .
Некоторые предполагают, что если текущая версия рабочего элемента содержит тег , то он будет включен в сгорание задним числом с самого начала. Например, если текущая версия рабочего элемента имеет тег "Клиент", предполагается, что рабочий элемент будет включен в сгорание с момента создания рабочего элемента.
Это не то, как работает фильтрация за прошлые периоды. Если бы фильтры применялись только на основе текущей версии рабочего элемента, диаграммы трендов не работали бы. Вы не можете удалить элемент из сгорания, удалив тег или задав для параметра Путь к области путь к области другой команды.
Примечание
Мы рассматриваем возможность добавления операнда "был когда-либо" в критерии фильтра в представлениях аналитики и мини-приложениях, таких как Burndown/Burnup. Эта функция позволяет создать фильтр, например "Состояние было когда-либо активным". Это означает, что редакция рабочего элемента будет соответствовать критерию фильтра, если любой редакции рабочего элемента когда-либо имел состояние = активно. Если вы считаете, что эта функция важна, вы можете проголосовать за нее на нашем Сообщество разработчиков сайте.
Исторические данные и приостановка или отключение аналитики
При приостановке аналитики данные сохраняются, но промежуточные задания не обновляются. Вы можете возобновить работу службы позже, а затем обновить данные.
Если администратор отключает аналитику, все промежуточные задания аналитики отключаются, а данные аналитики, хранящиеся в таблицах Аналитики, удаляются. Все аналитические данные, которые фиксируют исторические тенденции, теряются. Другие данные, хранящиеся в коллекции, не удаляются. Отменить это действие невозможно. После удаления исторических данных и трендовых данных восстановить их невозможно. Повторное включение аналитики не приведет к восстановлению исторических данных.
Если аналитика отключена или удалена, выполняются следующие действия:
- Промежуточные задания не выполняются, и таблицы Аналитики не будут содержать обновленные сведения.
- Данные таблицы удаляются, и при повторном включении аналитики все данные будут повторно повторяться с нуля.
Дополнительные сведения см. в статье Установка или включение службы Аналитики.
Итоги
Чтобы выполнить повторную обработку, при создании отчетов по историческим данным все фильтры применяются к версии рабочего элемента на исторический момент времени. Рабочие элементы будут отображаться в тренде, когда они соответствуют критериям фильтра. Они исчезнут из вашей тенденции, когда они больше не соответствуют критериям фильтра.
Похожие статьи
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по