Определение, запись, анализ ошибок программного обеспечения и управление ими в 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 или более поздних версий.

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

Категория	Требования
разрешения	— Чтобы просмотреть, следить за и редактировать рабочие элементы: Просмотр рабочих элементов в этом узле и Редактирование рабочих элементов в этом узле с установкой разрешений на 'Разрешить' . По умолчанию группа участников имеет эти разрешения. Дополнительные сведения см. в разделе "Настройка разрешений отслеживания работы". — Чтобы добавить теги к рабочим элементам: на уровне проекта установите разрешение создания нового определения тега на Разрешить. По умолчанию группа участников имеет это разрешение.
Уровни доступа	- член проекта. — Добавление новых тегов в рабочие элементы или просмотр или выполнение запросов на вытягивание: по крайней мере базовый доступ. — Чтобы просмотреть или отслеживать рабочие элементы: по крайней мере доступ уровня заинтересованного лица. Дополнительные сведения см. в разделе "О уровнях доступа". — Все члены проекта, включая участников группы Читатели, могут отправлять сообщения электронной почты, содержащие рабочие элементы.

Примечание.

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

Совет

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

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

На следующем рисунке показан тип рабочего элемента ошибки для процесса Scrum. Тип рабочего элемента "ошибка" для процессов Agile и Capability Maturity Model Integration (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 и элементы с контролем версий. Вы можете определить ссылки из рабочего элемента или из коммитов, запросов на вытягивание, или из других объектов разработки. Дополнительные сведения см. в разделе "Связывание рабочих элементов с разработкой " далее в этой статье.

---

Примечания.

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

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

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

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

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

---

Параметр

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

---

Рассматривайте ошибки как требования

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

Примечание.

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

---

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

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

Примечание.

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

---

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

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

Примечание.

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

---

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

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

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

Перед тем как настраивать процесс, рекомендуется ознакомиться с разделом О конфигурации и кастомизации досок Azure.

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

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

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

Совет

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

Добавить ошибку из вашего бэклога или доски

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

• Добавить баг из бэклога продукта

  

• Добавить баг с доски

  

Совет

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

Добавьте ошибку из спринт-бэклога или доски задач

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

• Добавить связанный дочерний баг из бэклога спринта

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

  

• Добавить связанный дочерний баг с доски

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

  

Создать ошибку с помощью средства тестирования

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

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

  

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

  

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

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

Гибкая методика (Agile)	Scrum	CMMI

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

Примечание.

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

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

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

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

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

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

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

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

Процесс scrum:

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

Процесс CMMI:

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

Совет

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

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

Автоматическое закрытие багов при слиянии pull-реквестов

Если ваша команда использует репозиторий Git, можно установить состояние в связанных задачах и других рабочих элементах так, чтобы они закрывались после успешного объединения pull-запросов. Для получения дополнительной информации см. раздел "Set work item state in pull request" далее в этой статье.

Перечисление и приоритизация ошибок

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

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

  

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

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

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

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

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

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

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

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

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

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

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

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

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

Элемент управления "Разработка" поддерживает связывание и отображение ссылок на сборки, коммиты Git и pull-запросы. Если используется репозиторий 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, разработанные корпорацией Майкрософт.

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

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

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

• Удаление, снятие или восстановление рабочих элементов
• Копирование или клонирование рабочего элемента

Бэклог продукта и доска

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

Совет

• О досках и Канбане
• Используйте вашу доску
• Переупорядочение карточек
• Добавление задач или дочерних элементов в виде контрольных списков

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

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

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

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

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

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