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


Сквозная трассировка

Azure DevOps Services

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

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

Возможность трассировки и связывания

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

Типы ссылок, используемые для репозиториев Git, как показано на следующем рисунке, — build, Found in build, Integrated in build, Branch, Commit, Pull Request и Integrated in release stage.

Conceptual image of code, build, and release links to work items.

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

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

Screenshot of Kanban board card, menu, choose New branch option.

Или выберите ветвь в форме рабочего элемента.

Screenshot of Work item form, Create a branch link.

Создание запроса на вытягивание из требования

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

Screenshot of Work item form, Create a pull request.

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

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

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

Screenshot of Kanban board card, menu, choose Add test option.

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

Ручное и автоматическое тестирование

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

Развертывание изменений в рабочей среде

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

Элементы управления развертывания и разработки

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

Work item form, Deployment control, Release Settings Stages.

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

Представление выпуска

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

Example showing multiple environments that the release is targeting.

Параметры выпуска

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

Screenshot of Release pipeline Options>Integrations settings.

Матрица трассировки требований

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

Матрица трассировки требований (RTM) гарантирует, что все требования, определенные для системы, проверяются в протоколах тестирования.

Отчеты о трассировки требований

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

Screenshot of the Requirements quality widget.

Возможность трассировки ошибок

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

Сведения об ошибках и источнике трассировки см. в разделе "Требования" для трассировки.

Возможность трассировки источника

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

Screenshot of source traceability.

Аналитика тестов

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