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* 

Существует два определения конструкции. Один момент указывает на текущую ветвь dev и другие точки в текущей ветви релиза.

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

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

• Технологические параметры> Build> проекты по строительству (пути к нескольким проектам )

Строка только всегда указывает на одно местоположение ветви в tfs, и единственная часть этого пути ветви, которая изменяется каждый раз, - это номер, связанный с текущим спринтом или выпуском. Так, например, сборка может переключиться с указателя на /developement/2.10_1/ на /developement/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 лет.