Поделиться через


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

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

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

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

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

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

Для Azure DevOps Services аналитика всегда включена. Вы не можете отключить его или приостановить.

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

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

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

Сервисы Azure DevOps

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

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

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

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

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

Дополнительные сведения см. в статье "Управление и включение функций".

Разрешения

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

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

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

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

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

Примечание.

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

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

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

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

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

  • Чтобы сообщить о активных ошибках или тенденциях ошибок, определите ошибки и обновите состояние ошибки по мере его исправления, проверки и закрытия.
  • Чтобы сообщить о невыполненной работе или других типах рабочих элементов, определите эти рабочие элементы и обновите их состояние при переходе от нового к закрытому. Рассмотрите все поля или теги, которые будут использоваться для фильтрации или группировки данных в отчете, и убедитесь, что они четко определены и согласованы.
  • Для поддержки сводных отчетов убедитесь, что существуют родительско-дочерние связи между элементами невыполненной работы продукта и задачами/ошибками, либо родительско-дочерние связи между функциями или элементами невыполненной работы портфеля и их подчиненными элементами. Дополнительную информацию см. в разделе "Упорядочьте невыполненные задачи и сопоставьте дочерние рабочие элементы с родителями".
  • Чтобы создать отчёты burndown или burnup, такие как Спринт-бёрндаун или Релиз-бёрндаун, убедитесь, что вы продумали, как вы хотите фильтровать и группировать данные в своём отчёте. Отчеты Burnup/Burndown ссылаются на набор сущностей WorkItemsSnapshot. Наборы сущностей моментальных снимков моделируются как ежедневные снимки. Данные агрегируются на основе назначений, сделанных по дате их назначения. Это означает, что для фильтрации отчета burndown/burnup на основе назначения полей или тегов, вы должны назначить поля или теги до начала периода, по которому хотите создать отчет. В противном случае поля и теги не регистрируются отчетом до даты их применения.
  • Чтобы поддерживать отслеживание требований, определите тестовые случаи и создайте ссылку Tested By из каждого тестового случая к истории пользователя, элементу невыполненной работы продукта или требованию. Определите тестовые случаи и свяжите тестовые случаи с родительскими PBIs с помощью ссылки Tested By. См. статью "Создание тестов".
  • (Рекомендуется) Чтобы поддерживать фильтрацию и группировку в отчете, назначьте путь области и путь итерации всем рабочим элементам. Сведения о том, как определить пути итерации и области, см. в разделе "Определение путей к областям" и назначение команде или определение путей итерации (спринтов) и настройка итераций команды.

Примечание.

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

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

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

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

    Совет

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

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

Конвейеры

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

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

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

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

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

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