Разрешения и предварительные требования для доступа к Аналитике в Azure DevOps

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 г. - Azure DevOps Server 2019 г.

Для работы с аналитикой и создания отчетов необходимо выполнить несколько предварительных требований, как описано в этой статье.

По умолчанию всем участникам проекта предоставляется доступ к данным аналитики для проектов, участниками которых они являются, включая участников, добавленных в группу читателей проекта. Пользователи с доступом заинтересованных лиц не имеют доступа к просмотру или изменению представлений аналитики.

Включение службы и функций

Как правило, аналитика всегда включена и доступна членам организации или коллекции для просмотра данных и создания отчета.

Служба аналитики

Для Azure DevOps Services аналитика всегда включена. Его нельзя отключить или приостановить.

Для Azure DevOps Server 2020 и более поздних локальных версий Аналитика автоматически устанавливается вместе с каждой создаваемой коллекцией проектов.

Для Azure DevOps Server 2019 необходимо сначала установить Analytics в каждой создаваемой коллекции проектов.

Вы можете приостановить и перезапустить службу. При приостановке новые данные не добавляются в аналитику.

Дополнительные сведения см. в статье Установка или включение службы Аналитики.

Azure DevOps Services

Чтобы использовать любую службу Azure DevOps, ее необходимо включить. Данные не могут быть записаны для отключенной службы. Службы могут быть включены или отключены для проекта по проекту.

Чтобы убедиться, что все службы включены, см. статью Включение и отключение службы.

Представления Analytics

Представления аналитики , концентратор на веб-портале, предоставляют упрощенный способ указания критериев фильтра для отчета Power BI на основе данных аналитики. Дополнительные сведения см. в статье Что такое служба аналитики?

Для доступа к представлениям аналитики необходимо включить его. Владелец организации или член группы "Администраторы коллекции проектов" может включить его для всех пользователей в организации. Или каждый участник проекта может включить его для себя.

Сведения о том, как это сделать, см. в статье Управление функциями и их включение.

Разрешения

Разрешения для службы задаются на уровне проекта, а для общих представлений аналитики — на уровне объекта.

В следующей таблице перечислены разрешения, доступные для установки, и назначения по умолчанию для групп безопасности проекта.

Разрешение читатели; Соавторы Администраторы проекта
Просмотр аналитики ✔️ ✔️ ✔️
Просмотр общего представления аналитики ✔️ ✔️
Добавление частного или общего представления аналитики ✔️ ✔️
Изменение и удаление общих представлений аналитики ✔️

Предварительные требования для отслеживания данных

Для сбора значимых данных команды разработчиков программного обеспечения должны выполнять осмысленные действия. В следующих разделах приведены общие рекомендации в зависимости от типа данных, по которым вы хотите сообщить.

Примечание

Наборы сущностей Branch, Pipeline и Test поддерживаются в Analytics версии 3.0-preview и более поздних версиях. Наборы сущностей моментальных снимков для поддержки заданий конвейера, запросов агента задач и размера пула агентов задач были добавлены с помощью предварительной версии Analytics версии 4.0 . Убедитесь, что указана версия аналитики, которая поддерживает интересующий набор сущностей.

Чтобы понять, по каким свойствам и значениям списка можно фильтровать или группировать данные, изучите метаданные Аналитики для соответствующего типа сущности.

Azure Boards и отслеживание работы

Сведения о доступных наборах сущностей, которые можно запрашивать, см. в справочнике по метаданным для Azure Boards Analytics.

Чтобы сообщить об отслеживании работы, командам необходимо выполнить несколько задач, чтобы обеспечить доступность значимых данных. Прежде чем определять запросы и отчеты аналитики, ознакомьтесь со следующими задачами.

  • Чтобы сообщить об активных ошибках или тенденциях, определите ошибки и обновите состояние ошибки по мере его исправления, проверки и закрытия.
  • Чтобы сообщить о невыполненной работе или других типах рабочих элементов, обязательно определите эти рабочие элементы и обновите их состояние по мере перехода из нового в закрытое. Подумайте о полях или тегах, которые будут использоваться для фильтрации или группировки данных в отчете, и убедитесь, что они четко определены и согласованы.
  • Для поддержки отчетов о свертки убедитесь, что между элементами невыполненной работы по продукту существуют связи между элементами невыполненной работы по продуктам и задачами или ошибками, либо между компонентами или элементами невыполненной работы портфеля и их дочерними элементами. Дополнительные сведения см. в статье Организация невыполненной работы и сопоставление дочерних рабочих элементов с родителями.
  • Чтобы создать отчеты о сгорании или сгорании, такие как спринт или сжечьспринт, убедитесь, что вы продумали, как фильтровать и группировать данные в отчете. Отчеты о сгорании и сгорании ссылались на WorkItemsSnapshot набор сущностей. Наборы сущностей моментальных снимков моделироваются как ежедневные моментальные снимки. Данные агрегируются на основе назначений, выполненных на дату их назначения. Это означает, что для фильтрации отчета о сгорании или сгорании на основе назначений полей или тегов необходимо назначить поля или теги до периода, за который вы хотите отчеты. В противном случае поля и теги не регистрируются отчетом до даты их применения.
  • Для поддержки отслеживания требований определите тестовые случаи и создайте ссылку Tested By из каждого тестового случая на историю пользователя, элемент невыполненной работы продукта или требование. Определить тестовые случаи и связать их с родительскими PBI с помощью ссылки типа Тест выполнил. См. раздел Создание тестов.
  • (Рекомендуется) Для поддержки фильтрации и группировки в отчете назначьте путь к области и путь итерации всем рабочим элементам. Сведения о том, как определить пути итерации и области, см. в разделах Определение путей к областям и назначение команде или Определение путей итерации (спринтов) и настройка итераций команды.

Примечание

Все настраиваемые поля, добавленные в тип рабочего элемента, доступны для использования в отчетах. Настраиваемые поля помечены Custom_DisplayNameOfField, где все пробелы были удалены из отображаемого имени.

Планы тестирования

Чтобы проверить ход выполнения плана тестирования и готовность к тестовой ситуации, командам необходимо выполнить следующие действия.

  • Определите тестовые случаи, планы тестирования и наборы тестов, а также укажите их текущее состояние. Дополнительные сведения см. в разделах Создание планов тестирования и наборов тестов и Создание тестовых случаев.
  • Обновите состояние тестовых объектов по мере их продвижения от конструктора до готово к закрытию.
  • Для ручных тестов, отмечать результаты каждого проверочного шага в тестовом случае как "пройдено" или "не пройдено".

    Совет

    Если тест проверочный, тест-инженеры должны отмечать шаги теста состояниями. Общий результат теста показывает состояние всех отмеченных шагов теста. Таким образом, тест получит состояние "не пройдено", если какой-либо из шагов теста отмечен как непройденный или не отмечен.

  • В случае автоматических тестов каждый тест автоматически отмечается как пройденный или завершенный неудачей.
  • (Рекомендуется) Для поддержки фильтрации и группировки в отчете назначьте путь к области и путь итерации для тестовых случаев, наборов тестов и планов тестирования.

Pipelines

Для создания отчетов о конвейерах командам необходимо определить конвейеры с помощью YAML и регулярно запускать конвейеры. Дополнительные сведения см. в статье Основные понятия для новых пользователей Azure Pipelines.

Кроме того, рассмотрите следующие действия.

  • Определите, какие данные вы хотите сообщить, и выберите правильный набор сущностей. Сведения о доступных наборах сущностей для запроса см. в справочнике по метаданным для Azure Pipelines Analytics.
  • Определите, по каким конвейерам вы хотите сообщать, и диапазон дат отчета. Вы захотите отфильтровать данные в соответствии с рекомендациями по запросам и свести к минимуму все проблемы с производительностью.

Конвейеры и тестирование

Чтобы сообщить о конвейерах и результатах тестов, обязательно добавьте тестовые задачи в определение конвейера. Дополнительные сведения см. в разделе Задачи сборки и выпуска — Тестирование.

Если вы только начинаете работу, рассмотрите возможность ознакомиться с этим модулем Learn Выполнение тестов качества в конвейере сборки с помощью Azure Pipelines.