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

Определение, запись, анализ ошибок программного обеспечения и управление ими в Azure Boards

  • Статья

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

Как отслеживать дефекты в коде и управлять ими? Как убедиться, что проблемы программного обеспечения и отзывы клиентов устранятся быстро для поддержки высококачественных развертываний программного обеспечения? Как добиться хорошего прогресса в новых функциях и решить свой технический долг?

Как минимум, вам нужен способ отслеживания проблем программного обеспечения, их приоритета, назначения участникам группы и отслеживания хода выполнения. Вы хотите управлять дефектами кода таким образом, чтобы соответствовать вашим методикам Гибкой работы.

Для поддержки этих сценариев Azure Boards предоставляет определенный тип рабочего элемента для отслеживания дефектов кода с именем "Ошибка". Рабочие элементы ошибок используют все стандартные функции других типов рабочих элементов с несколькими дополнительными. Общие сведения о стандартных функциях см. в разделе "Сведения о рабочих элементах" и типах рабочих элементов.

Ошибки также предоставляют следующие функции:

  • Параметры для каждой команды, чтобы выбрать способ отслеживания ошибок
  • Средства тестирования для отслеживания ошибок
  • Встроенная интеграция в Azure DevOps для отслеживания ошибок, связанных с сборками, выпусками и тестами

Примечание.

Типы рабочих элементов ошибки недоступны в базовом процессе. Процесс "Базовый" отслеживает ошибки в качестве проблем и доступен при создании проекта из Azure DevOps Services или Azure DevOps Server 2019.1 или более поздних версий.

Необходимые компоненты

  • Доступ к проекту. Добавьте его в проект.

  • Разрешения:

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

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

      Примечание.

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

  • Рабочие элементы электронной почты: все участники проекта, включая участников группы читателей , могут отправлять сообщения электронной почты, содержащие рабочие элементы.

Совет

Чтобы сообщить об ошибке, пользователь должен иметь как минимум доступ к заинтересованным лицам. У пользователя должен быть набор разрешений на изменение рабочих элементов в этом узле , чтобы разрешить путь к области, в котором они добавили ошибку. Дополнительные сведения см. в разделе "Настройка разрешений для отслеживания работы"

Тип рабочего элемента ошибки

На следующем рисунке показан тип рабочего элемента ошибки для процесса Scrum. Тип рабочего элемента ошибки для процессов интеграции с моделью гибкой и зрелости возможностей (CMMI) отслеживает аналогичную информацию. Он отображается в невыполненной работы продукта вместе с требованиями или на панели задач вместе с задачами.

Примечание.

Изображения, которые вы видите на веб-портале, могут отличаться от изображений, которые вы видите в этой статье. Эти отличия от обновлений, внесенных в веб-приложение, параметров, которые вы или администратор включили, и какой процесс был выбран при создании проекта: Agile, Basic, Scrum или CMMI. Базовый процесс доступен в Azure DevOps Server 2019 с обновлением 1 и более поздними версиями.

Снимок экрана: форма типа рабочего элемента ошибки для процесса Scrum в Azure DevOps Server 2020 и облачной службе.

Снимок экрана: форма типа рабочего элемента ошибки для процесса Scrum в Azure DevOps Server 2019.

Поля, относящиеся к ошибкам

Тип рабочего элемента ошибки использует некоторые поля, относящиеся к ошибкам. Чтобы записать начальную проблему и текущие обнаружения, используйте поля, описанные в следующей таблице. Сведения о полях, относящихся к ошибке, определенной для процесса интеграции модели зрелости возможностей (CMMI), см. в справочнике по полям "Ошибки", "Проблемы" и "Риски". Сведения обо всех остальных полях см. в разделе "Индекс поля рабочего элемента".

Поле, группа или вкладка

Использование

Шаги для воспроизведения (понятное имя=шаги repro)

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

Системные сведения,найденные в сборке

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

Критерии принятия

Укажите критерии, которые должны соответствовать, прежде чем ошибка может быть закрыта. Прежде чем начать работу, опишите критерии принятия клиентом как можно более четко. Команды должны использовать эти критерии в качестве основы для приемочных тестов и оценить, является ли элемент удовлетворительно завершенным.

Интегрированная в сборку

Указывает имя сборки, которая включает код, который исправляет ошибку. Это поле следует указать при устранении ошибки.

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

Сведения о том, как определить номера сборки, см. в разделе "Конфигурация классических конвейеров".

Приоритет1

  • 1. Продукт требует успешного разрешения рабочего элемента, прежде чем он будет отправлен и устранен в ближайшее время.
  • 2. Продукт требует успешного разрешения рабочего элемента перед его отправкой, но не нужно немедленно решать.
  • 3. Разрешение рабочего элемента является необязательным, основанным на ресурсах, времени и рисках.

Серьезность1

Субъективная оценка влияния на ошибку или рабочий элемент в проекте или программной системе. Например, если удаленная ссылка в пользовательском интерфейсе (редкое событие) приводит к сбою приложения или веб-страницы (серьезное взаимодействие с клиентом), можно указать серьезность = 2 — высокий и приоритет = 3. Допустимые значения и рекомендуемые рекомендации:

  • 1 — критическое: необходимо исправить. Дефект, который приводит к прекращению одного или нескольких системных компонентов или полной системы, или приводит к обширному повреждению данных. Для достижения необходимых результатов нет приемлемых альтернативных методов.
  • 2 . Высокий: рассмотрите возможность исправления. Дефект, который приводит к прекращению одного или нескольких системных компонентов или полной системы, или приводит к обширному повреждению данных. Допустимый альтернативный метод существует для достижения необходимых результатов.
  • 3 — средний: (по умолчанию) Дефект, который приводит к тому, что система создает неправильные, неполные или несогласованные результаты.
  • 4 - Низкий: незначительный или косметический дефект, который имеет приемлемые обходные пути для достижения необходимых результатов.

Развертывание

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

Разработка

Элемент управления "Разработка" поддерживает ссылки на объекты разработки и отображение ссылок на объекты разработки. К этим объектам относятся фиксации Git и запросы на вытягивание, а также наборы изменений TFVC и элементы с версиями. Вы можете определить ссылки из рабочего элемента или из фиксаций, запросов на вытягивание или другие объекты разработки. Дополнительные сведения см. в разделе "Связывание рабочих элементов с разработкой " далее в этой статье.

Примечания.

1 . Чтобы изменить выбор меню или список выбора, см. статью "Настройка интерфейса отслеживания работы". Метод настройки зависит от модели процесса, используемой проектом.

Выбор способа отслеживания ошибок в команде

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

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

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

Параметр

Выберите, когда вы хотите...

Отслеживание ошибок в качестве требований

Примечание.

  • Ошибки назначаются категории "Требования"

Отслеживание ошибок в качестве задач

  • Оценка работы над ошибками, похожими на задачи
  • Обновление состояния ошибки на спринте taskboards
  • Связывание ошибок с требованиями к дочерним элементам
  • Перетащите ошибки в область планирования, чтобы назначить ошибки спринту

Примечание.

  • Ошибки назначаются категории задач
  • Пользовательские истории (Agile), элементы невыполненной работы продукта (scrum) или требования (CMMI) являются естественным родительским типом рабочего элемента для ошибок
  • Ошибки не отображаются в планах доставки

Ошибки не отображаются в невыполненных работах или досках

  • Управление ошибками с помощью запросов

Примечание.

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

Настройка типа рабочего элемента

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

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

Перед настройкой процесса рекомендуется просмотреть сведения о настройке и настройке Досок Azure.

Сведения о настройке конкретного процесса см. в разделе "Настройка процесса наследования".

Сведения о настройке конкретного процесса см. в разделе "Настройка процесса наследования" или "Настройка локальной модели XML-процесса".

Добавление или запись ошибок

Вы можете определить ошибки из нескольких различных средств Azure DevOps. К этим средствам относятся невыполненные работы и доски и средства тестирования.

Совет

По умолчанию поле Title является единственным обязательным полем при создании ошибки. Вы можете добавлять ошибки таким же образом, как добавлять истории пользователей или элементы невыполненной работы продукта с помощью Azure Boards. Можно сделать некоторые поля обязательными, добавив условные правила на основе изменения состояния. Дополнительные сведения см. в разделе "Добавление правила в тип рабочего элемента".

Добавление ошибки из невыполненной работы или доски

Если ваша команда решила управлять ошибками с требованиями, вы можете определить ошибки из невыполненной работы продукта или доски. Дополнительные сведения см. в статье "Создание невыполненной работы продукта" или "Использование доски".

  • Добавление ошибки из невыполненной работы продукта

    Снимок экрана: добавление ошибки из невыполненной работы продукта.

  • Добавление ошибки из доски

    Снимок экрана: добавление ошибки из доски.

Совет

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

Добавление ошибки из невыполненной работы или области задач спринта

Если ваша команда решила управлять ошибками с задачами, вы можете определить ошибки из вашей доски, невыполненной работы продукта, невыполненной работы с спринтом или Спринт taskboard. Вы добавляете ошибку в качестве дочернего элемента в рабочий элемент невыполненной работы продукта.

Создание ошибки из средства тестирования

Два средства тестирования, которые можно использовать для добавления ошибок во время тестирования, включают в себя средство запуска тестов веб-портала и расширение Test &Feedback.

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

    Снимок экрана: средство запуска тестов, где можно добавить ошибку.

  • Расширение тестов и отзывов: при выполнении поисковых тестов можно выбрать команду "Создать ошибку " или "Создать задачу". Дополнительные сведения см. в разделе "Исследование тестирования" с расширением Test и Feedback.

    Снимок экрана: расширение

Жизненный цикл ошибок и состояния рабочего процесса

Как и во всех других типах рабочих элементов, тип рабочего элемента ошибки имеет хорошо определенный рабочий процесс. Каждый рабочий процесс состоит из трех или более состояний и причин. Причины указывают, почему элемент переходит из одного состояния в другое. На следующих изображениях показан рабочий процесс ошибки по умолчанию, определенный для процессов Agile, Scrum и CMMI .

Гибкая методика (Agile) Scrum CMMI
На схеме показаны состояния рабочего процесса ошибки в шаблоне процесса Agile. На схеме показаны состояния рабочего процесса ошибки в шаблоне процесса Scrum. На схеме показаны состояния рабочего процесса ошибки в шаблоне процесса CMMI.

Для ошибок Scrum измените состояние с "Зафиксировано" (аналогично "Активно") на "Готово". Для Agile и CMMI сначала устраните ошибку и выберите причину, указывающую на исправление ошибки. Как правило, пользователь, создавший ошибку, проверяет исправление и обновляет состояние от разрешенного до закрытого. Если вы найдете больше работы после устранения или закрытия ошибки, повторно активируйте ее, установив для состояния значение "Зафиксировано" или "Активный".

Примечание.

Ранее тип рабочего элемента с ошибкой гибкого процесса имел правило, которое переназначило ошибку пользователю, создавшему его. Это правило было удалено из системного процесса по умолчанию. Эту автоматизацию можно восстановить, добавив правило. Сведения о процессе наследования см. в разделе "Автоматизация переназначения на основе изменения состояния".

Проверка исправления

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

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

Закрытие ошибки

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

Гибкий процесс:

  • Отложено: отложить исправление ошибки до следующего выпуска продукта.
  • Исправлено: ошибка проверяется как исправленная.
  • Дубликат: ошибка отслеживает еще одну ошибку, определенную в данный момент. Вы можете связать каждую ошибку с типом повторяющихся и повторяющихся ссылок и закрыть одну из ошибок.
  • Как разработано: функция работает как разработанная.
  • Не удается воспроизвести: тесты показывают, что ошибка не может быть воспроизведена.
  • Устаревшее: функция ошибки больше не входит в продукт.
  • Скопировано в невыполненную работу: история пользователя была открыта для отслеживания ошибки.

Процесс scrum:

  • Не ошибка: ошибка проверяется, что она не является ошибкой.
  • Дубликат: ошибка отслеживает еще одну ошибку, определенную в данный момент. Вы можете связать каждую ошибку с типом повторяющихся и повторяющихся ссылок и закрыть одну из ошибок.
  • Удалено из невыполненной работы. Ошибка проверяется, что она не является ошибкой. Удалите ошибку из невыполненной работы.
  • Завершена работа. Ошибка была проверена как исправленная.

Процесс CMMI:

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

Совет

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

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

Автоматизация закрытия ошибок при слиянии запросов на вытягивание

Если команда использует репозиторий Git, можно задать состояние в связанных ошибках и других рабочих элементах, чтобы закрыть после успешного объединения запросов на вытягивание. Дополнительные сведения см. в разделе "Настройка состояния рабочего элемента" в запросе на вытягивание далее в этой статье.

Перечисление и устранение ошибок

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

Запросы ошибок

Откройте общий запрос или используйте редактор запросов для создания полезных запросов ошибок, таких как следующие параметры:

  • Активные ошибки по приоритету (State <> Done или State <> Closed)
  • Ошибки хода выполнения (State = Committed или State = Active)
  • Ошибки для исправления целевого выпуска (Tags Contains RTM)
  • Последние ошибки, такие как ошибки, открытые за последние три недели (Created Date > @Today-21)

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

Режим триажа в результатах запроса

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

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

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

Снимок экрана: результаты запроса, активные ошибки и режим триажа справа.

Упорядочение и назначение ошибок спринту

Если команда отслеживает ошибки в качестве требований, просмотрите список активных ошибок из невыполненной работы. С помощью функции фильтра можно сосредоточиться исключительно на ошибках. Из невыполненной работы продукта можно также выполнить следующие задачи:

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

Элементы панели задач и элементы списка запросов

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

Можно назначить задачи или ошибки итерации, но не связать их с родительским элементом невыполненной работы. Эти элементы отображаются в созданном запросе, но могут не отображаться в самой панели задач. Система запускает запрос, а затем применяет несколько фоновых процессов перед отображением элементов панели задач.

Эти причины могут привести к тому, что рабочие элементы, принадлежащие категории задач, не отображаются в спринте невыполненной работы или в области задач:

  • Задача или ошибка не связана с родительским элементом невыполненной работы. Только ошибки и задачи связаны с элементом невыполненной работы родительского продукта (Scrum), историей пользователя (Agile) или требованием (CMMI) с путем итерации, установленным на странице невыполненной работы с спринтом.
  • Задача или ошибка является родительским элементом другой задачи или ошибки, или история пользователя является родительским элементом другой истории пользователя. Если вы создаете иерархию задач, ошибок или пользовательских историй, отображаются только задачи дочернего уровня или истории дочернего уровня в нижней части иерархии. Дополнительные сведения см. в разделе "Устранение неполадок с переупорядочением и вложением".
  • Связанный родительский элемент задачи или ошибки соответствует элементу невыполненной работы, определенному для другой команды. Или путь к области родительского элемента невыполненной работы задачи отличается от пути к области задачи или ошибки.

Создание встроенных тестов, связанных с ошибками

Когда команда отслеживает ошибки в качестве требований, можно добавить тесты для проверки исправлений ошибок.

Снимок экрана: доска, три столбца, показывающие встроенные тесты, добавленные и связанные с ошибками.

Обновление состояния ошибки

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

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

    Снимок экрана: доска, в которой можно перетащить ошибку для обновления состояния.

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

    Снимок экрана: панель задач, в которой можно перетащить ошибку для обновления состояния.

Настройка доски для отслеживания промежуточных состояний

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

Автоматизация переназначения ошибок на основе состояния рабочего процесса

Чтобы автоматизировать выбор действий, добавьте настраиваемые правила в тип рабочего элемента ошибки. Например, добавьте правило, как показано на следующем рисунке. Это правило указывает, чтобы переназначить ошибку пользователю, открывшему ошибку, когда член команды разрешает ошибку. Как правило, этот пользователь проверяет, исправлена ли ошибка и закрывает ошибку. Дополнительные сведения см. в разделе "Применение правил к состояниям рабочего процесса" (процесс наследования).

Снимок экрана: правило, определенное для переназначения ошибки на основе разрешенного состояния.

Настройка состояния рабочего элемента в запросе на вытягивание

При создании запроса на вытягивание можно задать значение состояния связанных рабочих элементов в описании. Следуйте синтаксису: {state value}: #ID

При слиянии запроса на вытягивание система считывает описание и обновляет состояние рабочего элемента. В следующем примере для рабочих элементов #300 и #301 задано значение "Разрешено", а для #323 и #324 задано значение "Закрыто".

Снимок экрана: настройка состояния рабочего элемента в запросе на вытягивание.

Примечание.

Для этой функции требуется установить обновление Azure DevOps Server 2020.1. Дополнительные сведения см. в заметках о выпуске Azure DevOps Server 2020 с обновлением 1 RC1, досках.

Интеграция с Azure DevOps

Одним из методов, используемых Azure DevOps для поддержки интеграции, является связывание объектов с другими объектами. Помимо связывания рабочих элементов с рабочими элементами, можно также связать рабочие элементы с другими объектами. Ссылка на объекты, такие как сборки, выпуски, ветви, фиксации и запросы на вытягивание, как показано на следующем рисунке.

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

Вы можете добавить ссылку из рабочего элемента или из объектов сборки и выпуска.

Элемент управления "Разработка" поддерживает связывание и отображение ссылок на сборки, фиксации Git и запросы на вытягивание. Если используется репозиторий TFVC, он поддерживает ссылки на наборы изменений и элементы с версиями. При выборе ссылки откроется соответствующий элемент на новой вкладке браузера. Дополнительные сведения см. в разделе "Разработка диска Git" из рабочего элемента.

Снимок экрана: элемент управления разработкой формы рабочего элемента с примерами ссылок на сборку, запросы на вытягивание и фиксации.

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

Снимок экрана: элемент управления

Конвейеры часто определяются для автоматического запуска при возникновении новой фиксации в репозитории Git. Рабочие элементы, связанные с конвейером фиксации, отображаются в процессе выполнения конвейера при настройке параметров конвейера. Дополнительные сведения см. в разделе "Настройка конвейера".

Снимок экрана: параметры конвейера с автоматическим связыванием рабочих элементов в этом запуске из выделенной ветви.

Создание или изменение рабочего элемента при сбое сборки

Если вы используете классические конвейеры (а не YAML), можно создать рабочие элементы при сбое сборки. Дополнительные сведения см. в статье "Создание рабочего элемента при сбое".

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

Снимок экрана: две активные диаграммы запросов ошибок, тенденции ошибок по состоянию и по приоритету.

Дополнительные сведения о запросах, диаграммах и панелях мониторинга см . в управляемых запросах, диаграммах и панелях мониторинга.

Использование представлений Аналитики и службы Аналитики для создания отчетов об ошибках

Служба Аналитики — это платформа отчетов для Azure DevOps. Она заменяет предыдущую платформу на основе служб SQL Server Reporting Services.

Представления аналитики предоставляют предварительно созданные фильтры для просмотра рабочих элементов. Для создания отчетов об ошибках поддерживаются четыре аналитических представления. Эти представления можно использовать как определенные или дальнейшие изменения для создания настраиваемого отфильтрованного представления.

  • Ошибки — все журналы по месяцам
  • Ошибки — последние 26 недель
  • Ошибки — последние 30 дней
  • Ошибки - Сегодня

Дополнительные сведения об использовании аналитических представлений см. в разделе "Сведения об аналитике" и "Создание активного отчета об ошибках" в Power BI на основе пользовательского представления аналитики.

С помощью Power BI можно создавать более сложные отчеты, чем запрос. Дополнительные сведения см. в разделе "Подключение с помощью соединителя данных Power BI".

Предопределенные отчеты об ошибках SQL Server

Следующие отчеты поддерживаются для процессов Agile и CMMI.

Для этих отчетов требуется, чтобы для проекта были настроены службы SQL Server Analysis Services и SQL Server Reporting Services. Сведения о добавлении отчетов SQL Server для проекта см. в статье "Добавление отчетов в проект".

Расширения Marketplace

Существует несколько расширений Marketplace, связанных с ошибками. См. Marketplace для Azure DevOps.

Дополнительные сведения о расширениях см . в расширениях Azure Boards, разработанных корпорацией Майкрософт.

Следующие шаги

Использование шаблонов для добавления и обновления рабочих элементов

Невыполненная работа продукта и доска

Board

Невыполненная работа с спринтом и панелью задач

Интеграция в Azure DevOps

Отраслевые ресурсы