Не удается назначить рабочие элементы релизам в DevOps Azure

Question

Я пришел с использованием Rally и Pivotal Tracker.В обоих случаях я мог назначать рабочие элементы для выпусков в качестве инструмента планирования и иметь историческую запись тех рабочих элементов, которые были развернуты.

Даже несмотря на все весьма специфические рекомендации Microsoft по DevOps Azure, он не знает, как организовать работу с будущими выпусками.Я не вижу места, где можно даже связать рабочий элемент с выпуском.Есть ли что-то, чего мне не хватает во всей документации, или есть какая-то обходная стратегия, более надежная, чем просто использование тегов для проактивного планирования выпуска?Или Microsoft ожидает, что я использую какой-то отдельный инструмент управления продуктами для управления рабочими элементами в версиях?

Answer 1

Для этого используется несколько методов, а не «односторонний»:

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

   Backlog Iteration
   + Release 1.0
     + Sprint 1
     + Sprint 2
     + Sprint 3
   + Release 2.0
     + etc
   

-

использовать теги для релизов.Добавьте тег [Выпуск 1.0] поверх всех рабочих элементов, включенных в этот выпуск. Это один из наиболее гибких параметров.

использование конвейеров Azure для отслеживания того, какие рабочие элементы былисвязанный с которым Git фиксирует и таким образом был включен в который Build Artifact.Отслеживайте артефакты сборки в разных средах, чтобы увидеть, какие рабочие элементы были развернуты в среде, просмотрев промежуточные сборки.

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

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

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