Не удается назначить рабочие элементы релизам в 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
   

-

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

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

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

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

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

Answer 2

В дополнение к ответу @jessehouwing я могу добавить

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

Однако у этого варианта, как и у других вариантов, есть свои недостатки. По моему опыту (пробовал 1, 2, 5, сейчас настраиваю 3):

1. Как написал Джесси... это почти идеально, в том числе в отношении запросов и дашбордов - если только работа не перекрывается, что (я думаю) происходит естественным образом ближе к концу одного цикла выпуска и началу другого. По моему опыту, чистых сокращений в циклах спринта... не существует :) Для общих целей (dahsboards) это может быть не важно, но для других целей это слишком нечетко.
2. Много работы по поддержанию всех тегов в актуальном состоянии, особенно когда товары меняются. Склонен «что-то упускать». Тем не менее, его легко использовать в запросах/панелях мониторинга и он будет наиболее гибким - я думаю, что это единственный вариант здесь, который может обрабатывать элементы, являющиеся частью более чем одного выпуска.
3. Это, вероятно, наиболее точный вариант фактической поставки (когда все ссылки выполнены правильно), но не помогает при планировании будущих версий.
4. Ручная работа, как с тегами, но, возможно, более выраженная/очевидная и может быть принудительно реализована (требуется проверка). Мы еще не пробовали этот вариант, поскольку он требует согласования с администраторами Azure и, возможно, другими командами. Все остальные опции работают из коробки со стандартными правами.
5. Почти как 1. но без нечеткого перекрытия (хорошо), но запросить его невозможно (плохо). Я искал запрос типа «все ниже родительского X», но не нашел решения. И тогда инициативы имеют значение «версия», что нас устраивает, но другие могут захотеть использовать другую семантику, например «Большая тема А», независимо от того, что входит в какой выпуск.

Итак... Я, наверное, попробую 4. дальше и посмотрю, к чему это приведет :)