Определение, запись, анализ ошибок программного обеспечения и управление ими в 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. По умолчанию группа участников имеет этот набор разрешений. Дополнительные сведения см. в разделе "Настройка разрешений и доступ для отслеживания работы".
• Чтобы добавить новые теги для добавления в рабочие элементы, необходимо иметь базовый доступ или более высокий уровень и иметь разрешения на создание нового определения тегов проекта, заданных в значение Allow. По умолчанию группа участников имеет этот набор разрешений. Даже если разрешение явно задано для заинтересованных лиц, у них нет разрешения на добавление новых тегов, так как они запрещены на уровне доступа. Дополнительные сведения см. в кратком справочнике по правам доступа для заинтересованных лиц.
• Все члены проекта, даже члены группы читателей , могут отправлять сообщения электронной почты, содержащие рабочие элементы.

Совет

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

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

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

Примечание.

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

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

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

---

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

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

---

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

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

---

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

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

---

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

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

---

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

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

---

Приоритет¹

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

---

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

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

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

---

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

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

---

Разработка

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

---

Примечания:

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

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

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

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

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

---

Параметр

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

---

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

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

Примечание.

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

---

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

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

Примечание.

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

---

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

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

Примечание.

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

---

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

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

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

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

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

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

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

Совет

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

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

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

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

  

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

  

Совет

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

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

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

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

  

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

  

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

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

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

  

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

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

Как и во всех других типах рабочих элементов, тип рабочего элемента ошибки имеет хорошо определенный рабочий процесс. Каждый рабочий процесс состоит из трех или более состоянийи причин. Причины указывают, почему элемент переходит из одного состояния в другое. На следующих изображениях показан рабочий процесс ошибки по умолчанию, определенный для процессов 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) с путем итерации, заданным для спринта.
• Задача или ошибка является родительским элементом другой задачи или ошибки, или история пользователя является родительским элементом другой истории пользователя. Если вы создали иерархию задач, ошибок или историй пользователей, отображаются только задачи уровня ребенка или истории дочернего уровня в нижней части иерархии.
• Связанный родительский элемент задачи или ошибки соответствует элементу невыполненной работы, определенному для другой команды. Или путь к области родительского элемента невыполненной работы задачи отличается от пути к области задачи или ошибки.

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

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

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

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

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

  

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

  

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

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

• Добавление столбцов в доску Kanban
• Настройка буфера задач спринта
• Запросы на изменение доски Kanban

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

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

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

При создании запроса на вытягивание можно задать значение состояния связанных рабочих элементов в описании. Следуйте синтаксису: {state value}: #ID При слиянии запроса на вытягивание система считывает описание и обновляет состояние рабочего элемента. В следующем примере для рабочих элементов #300 и #301 задано значение "Разрешено", а для #323 и #324 задано значение "Закрыто".

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

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

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

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

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

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

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

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

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

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

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

Мониторинг состояния ошибок, назначений и тенденций

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

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

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

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

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

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

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

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

Расширения Marketplace

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

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

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

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

Связанные статьи

• Перемещение, изменение типа или удаление рабочих элементов
• Копирование или клонирование рабочего элемента

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

• Невыполненные работы, портфели и управление проектами Agile
• Создание невыполненной работы
• Определение признаков и эпических элементов
• Упорядочение невыполненной работы, сопоставление дочерних рабочих элементов с родителями
• Интерактивный фильтрация невыполненных работ, доски, запросы и планы
• Прогнозирование невыполненной работы продукта

Канбан доска

• О досках и Канбане
• Краткое руководство по Kanban board
• Изменение порядка карта
• Добавление задач или дочерних элементов в виде списков проверка

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

• Scrum и работа с рекомендациями по спринтам
• Назначение элементов невыполненной работы спринту
• Добавление задач
• Обновление панели задач

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

• Связывание историй пользователей, проблем, ошибок и других рабочих элементов
• Следуйте рабочему элементу или запросу на вытягивание
• Настройка номеров запуска или сборки

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

• Хороший и плохой технический долг (и как TDD помогает) Хенрик Книберг
• Управление техническим долгом , опубликованным Свеном Иоганном и Эберхардом Вольфом