Блог

Мы используем службы Visual Studio Team Services.

У нас есть Prod-Branch, который создается с помощью нашего определения Prod-Build и развертывается с помощью нашего определения Prod-Release-Definition в наших тестовых / интеграционных и производственных средах.

При развертывании каждого выпуска продукта для клиента мы создаем ветку Prod-Rel-Version-x.x.x из ветки Prod (на случай, если это понадобится для исправления).

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

После спринта (или время от времени) ветвь разработки объединяется с основной ветвью, а затем с ветвью Prod. Оттуда он развертывается на разных этапах для тестирования заказчиком.

При наличии исправления мы исправляем ошибку в ветке Prod-Rel-Version-x.x.x и хотели бы повторно использовать наше существующее определение Prod-Build-Definition для создания этой версии исправления и развертывания на разных этапах с помощью существующего определения выпуска продукта для тестированияи переходим к этой версии.

Как мы можем повторно использовать наше определение Prod-Build-Definition в этой другой ветке (ветка Prod-Rel-Version-x.x.x вместо ветки Prod)?

Когда я смотрю на определение сборки, я думаю, что это было бы возможно, просто отредактируйте путь к серверу (репозиторий> Сопоставления) от $/NameOfOurApp/Prod до $/NameOfOurApp/Prod-Rel-Version-x.x.x) …это должно сработать или нет? Но из того, что я прочитал, невозможно использовать переменные сборки в сопоставлениях серверов, поэтому я не могу изменить эту переменную, например, в диалоговом окне Queue new Build…

Каков наилучший способ выполнить мой сценарий?

Единственный способ сделать это — создать единое определение сборки, которое загружает все ветви. Затем используйте переменные в задачах, чтобы выбрать версию для сборки. Это очень быстро станет очень запутанным (и медленным).

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

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

Обновить

VSTS и TFS 2018 теперь поддерживают использование переменных в определении рабочей области.