Как связать рабочие элементы для сборки конвейера yaml при использовании ветвей выпуска?
В Azure DevOps при использовании ветвей выпуска (потока) вместе с конвейерами YAML Build(+Release). Я хотел бы иметь возможность быстро определить список всех рабочих элементов, которые являются новыми/измененными со времени предыдущего выпуска.
Функция Автоматически связывать рабочие элементы со сборками или выпусками, похоже, хорошо работает с запросами на включение (PR) в ветку main. Но если релизы выполняются путем создания веток (например, releases\v1.0) из последней фиксации ветки main, такое «автоматическое связывание» не представляется возможным, поскольку вам нужно явно выбрать ветку (единственный подстановочный знак в списке — * - не могу войти/выбрать releases\*.
Я думаю, что моим идеалом было бы, если бы существовал способ, которым при создании ветки выпуска (например, releases\v1.2) и последующем запуске конвейера сборки yaml его «Связанные рабочие элементы» ограничивались бы только теми, которые связаны с коммитами с момента последнего выпуска (например, с releases\v1.1).
Раньше мы делали PR из main в одну release ветку — что не совсем идеально, так как, во-первых, это создает новый коммит слияния (плюс это похоже на хак)
Заранее спасибо.
Ответы 1
Я думаю, что моим идеалом было бы, если бы был способ, которым при создании ветки выпуска (например, Releases\v1.2) и последующем запуске конвейера сборки yaml, его «Связанные рабочие элементы» ограничивались бы только теми, которые связаны с фиксациями, поскольку последний выпуск (например, с момента выпуска\v1.1).
Если вы создаете releases/v1.2 базы на releases/v1.1, и в настройках указываете releases/v1.1. образец, как показано ниже:
Запустите конвейер на основе releases/v1.2 для the first run. Он будет включать рабочие элементы из releases/v1.1.
Но если releases/v1.2 создан из main ветки, даже если вы укажете releases/v1.1 в настройках, рабочие элементы not будут включены.
Пожалуйста, проверьте документ на предмет автоматического связывания рабочих элементов с поведением сборки.
Спасибо, Уэйд, за эти подробности, очень ценю. Итак, мне было бы очень интересно узнать, как Microsoft, которая заявляет, что использует стратегию Release Flow (Learn.microsoft.com/en-us/devops/develop/…), отслеживает рабочие элементы, которые входят в каждый выпускать. Потому что, судя по тому, что я вижу, единственный способ отслеживать только рабочие элементы для каждого последующего выпуска — это иметь одну ветку выпуска (что ограничивает возможность управления перекрывающимися выпусками). Еще раз спасибо!
Стратегия Release Flow показывает, как Microsoft развивается с помощью DevOps для предоставления онлайн-сервисов, но на самом деле это не сильно связано с рабочими элементами. Вам следует следовать документу автоматически связывать рабочие элементы со сборками для подробного поведения. Или вам нужно создать запрос на включение, manually выбрать рабочие элементы для сборки.
Спасибо, Уэйд, мне просто было любопытно, используют ли они функцию автоматического связывания рабочих веток релиза, но, похоже, они этого не делают. Спасибо за подтверждение, я приму ваш ответ, поскольку на данный момент он кажется наиболее близким к моему ответу. Спасибо еще раз.
Рад помочь! Счастливый день!
У нас есть возможность связывать рабочие элементы при разрешении PR. Проверьте, подходит ли это вам.