VSTS Release Management: фильтрация по ветке в источнике артефакта

Я использую сборку VSTS для запуска сборки CI. Это определение сборки одинаково для всех моих веток git (master, development, features и т. Д.).

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

Я думаю, что это довольно просто и обычно. Фактически, это в значительной степени то, что задокументировано в Microsoft типичный вариант использования Release Management.

Я хочу настроить оба этих конвейера для автоматического запуска с помощью триггера «Непрерывное развертывание». Когда я выбираю этот триггер, я должен выбрать источник артефакта.

К сожалению, источник артефактов принимает все артефакты (независимо от ветки), поступающие из заданного определения сборки (моя сборка CI). Поскольку я использую одно и то же определение сборки CI для всех своих веток, похоже, что я не могу настроить свои два конвейера выпуска в «Непрерывном развертывании» и по-прежнему использую то же определение сборки в качестве источника артефактов.

Кто-нибудь знает, как использовать одно и то же определение сборки для нескольких определений выпуска, но запускать выпуск только для определенной ветки? Кто-нибудь знает способ фильтрации по ветке, когда мы определяем источник артефакта?


person mabead    schedule 13.04.2016    source источник
comment
Я нахожусь в аналогичном затруднительном положении, за исключением того, что сборка запускается созданием запроса на перенос. Это вызывает релиз, и этого не должно быть. Сборки PR выполняются в отдельной ветке (например, refs / pull / 16 / merge). Я тоже хотел бы отфильтровать триггер выпуска по ветке, чтобы он запускался только созданным мастером.   -  person Jeff Shepler    schedule 15.04.2016
comment
Ваш сценарий даже более проблематичен, чем тот, который я описал! Я предлагаю вам либо отправить его в Visual Studio UserVoice, либо проголосовать за и прокомментировать мою доступную запись здесь.   -  person mabead    schedule 18.04.2016


Ответы (2)


Настройка развертывания выпуска для конкретной ветки

  1. Перейти к управлению выпусками в VSTS
  2. Перейти к определению выпуска
  3. Перейти к триггерам вкладок
  4. Добавить триггер непрерывного развертывания
  5. Здесь вы можете выбрать конкретную ветку (для ветки)

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

Наличие функции

  • Эта функция доступна в VSTS
  • В локальной версии TFS он должен был быть доступен в версии Server 2017.1, но по-прежнему недоступен в версии 2018.1.
person Frontend Art    schedule 02.12.2016
comment
Имейте в виду, что настройка фильтра веток доступна только в том случае, если исходный код находится в репозитории VSTS / TFS. При использовании внешних источников, таких как github, фильтр веток не отображается / не доступен. - person Teknokraten; 01.05.2017
comment
Я использую 2017.2, и эта функция все еще отсутствует. Если только это не Git - person Erik Funkenbusch; 07.10.2017
comment
все еще не там :( - person Alexander Efimov; 16.07.2018

В настоящее время в VSTS Release Management нет возможности выполнить условное развертывание на основе ветки.

Альтернативой может быть создание отдельных BD для разных ветвей, а затем их настройка в качестве источников артефактов для RD.

Это также даст пользователям ясность об артефакте по его названию.

person Harshil Lodhi    schedule 13.04.2016
comment
Это позор. Поскольку в Git ветки создаются и удаляются очень часто, у нас есть только одно определение сборки. Это позволяет избежать разговоров между командой разработчиков и командой DevOps, которые настраивают определения сборки. Имея один BD для всех веток, DevOps вообще не участвует при создании / удалении веток. - person mabead; 13.04.2016
comment
Да, но люди в основном выпускают из фиксированной ветки, такой как master или release, в которой разработчики объединяют свои изменения. Таким образом, основные ветки не удаляются. Поэтому имеет смысл иметь другое определение сборки для другой ветки. Для этого вам следует поднять голос пользователя. Возможно, есть и другие, кому нужна такая же функциональность. Если вы можете поделиться своим сценарием, я могу придумать обходной путь. - person Harshil Lodhi; 13.04.2016
comment
На мой взгляд, создание нескольких BD только для этого излишне и расточительно (с точки зрения времени). В моем случае (см. Мой комментарий выше) это не поможет. Настроив политику ветвления для создания сборки для PR, вы можете потребовать другую сборку после обновления главной ветки, но вы не можете указать другой BD. Я хочу, чтобы релиз запускался из основной сборки, а не из PR-сборки. - person Jeff Shepler; 15.04.2016