TFS - определение сборки с часто меняющимся путем ветвления

Question

Моя команда использует подход ветвления для релиза и спринта. Таким образом, у нас обычно есть новая ветка от Main (интеграция) для текущего спринта и ветка от Main для каждого выпуска.

Main Branch
|
 -- Development Folder
|   |
|   -- Sprint 2.10_1 Branch
|   -- Sprint 2.10_2 Branch   *current*
|
 -- Release Folder
|   |
|   -- Release 2.8.0 Branch
|   -- Release 2.9.0 Branch   *current*

Есть два определения сборки. Один указывает на текущую ветку разработки, а другой - на текущую ветку выпуска.

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

• Настройки источника> папки управления источником (несколько активных и скрытых путей)

• Параметры процесса> Build > проекты для сборки (пути к нескольким проектам)

Сборка всегда указывает только на одно местоположение ветвления в tfs, и единственная часть этого пути ветвления, которая меняется каждый раз, это число, связанное с текущим спринтом или выпуском. Так, например, сборка может перейти от указания с /development/2.10_1/ на /development/2.10_2/.

Есть ли способ определить базовый путь один раз в определении сборки, а затем использовать его по всему определению? Таким образом, каждый раз, когда мы переключаем ветки, нам нужно только указать путь к ветке в одном месте? Более того, можно ли управлять значением этой переменной за пределами определения сборки, чтобы его можно было использовать несколькими определениями сборки? Может ли значение переменной быть динамическим в зависимости от активной итерации для проекта?

Или записи пути в определении сборки могут быть определены таким образом, чтобы они относились к ветви?

Какие-либо предложения? Спасибо!

Answer 1

Я настроил наши сборки так, чтобы они использовали пользовательский параметр $(BranchToBuild), который вставляется во все пути сборки в сборке. Это устраняет проблему, возникшую в разделе определения "проекты для сборки".

Затем этот параметр можно передать в сборку, добавив /p:BranchToBuild=2.10_2 к параметрам сборки в диалоговом окне "Построение очереди", так что вы можете вручную выбрать любую ветвь для сборки при каждой сборке в очереди.

Вы также можете установить параметры по умолчанию в определении вашей сборки, чтобы по умолчанию /p:BranchToBuild=2.10_2 для каждой сборки - каждый раз, когда вы делаете новую ветку "текущей", вы можете просто изменить это значение по умолчанию, и все последующие сборки будут автоматически использовать правильную ветку (но вы все равно можете вернуться и легко выполнить сборку из любой предыдущей ветви, для пример, если вам нужно объединить исправление ошибки с предыдущим выпуском)

Единственная проблема с этим (как вы заметили) заключается в том, что вы должны также отобразить код для ветви на сервер сборки, чтобы его можно было получить из системы контроля версий. Однако для этого есть ярлык - в определении сборки выберите все сопоставления для старой ветки (10.1_1) и скопируйте их. Вставьте в текстовый редактор, и вы увидите, что каждый просто становится простой строкой текста. Теперь вы можете выполнить глобальный поиск и заменить 10.1_1 на 10.1_2, а затем скопировать и вставить весь набор сопоставлений обратно в определение сборки. Мили быстрее и менее подвержены ошибкам, чем ручное редактирование каждой строки в отображениях.

Все вышеперечисленное означает, что на создание новой ветки у меня уходит около 30 секунд.

Предостережение заключается в том, что определение сборки указывает на файл vcproj, который управляет сборкой, и получает этот файл до запуска самой сборки. Поэтому проблематично поместить ваше определение сборки в ветку. Обычно это не проблема, но иногда, когда вам нужно обновить определение сборки, это может привести к поломке веток, если вы также не укажете определение сборки вручную на правильный вариант vcproj. Обычно я обхожу это, избегая серьезных изменений в сборке, так что это меня укусило только один раз за последние 7 лет.