Как сделать так, чтобы несколько параметров конфигурации TeamBuild 2015 не применялись ко всем шагам?

Мне нравится концепция MultiConfiguration через вкладку «Параметры» в TFS 2015 TeamBuild. Но я не хочу, чтобы результирующая «матричная сборка» применялась к каждому шагу определения сборки.

Обычно мы хотим запускать пользовательские «этапы компиляции post VS SLN» only once после компиляции каждой конфигурации. И мы хотим, чтобы артефакты, сгенерированные на этих шагах, «удалялись» only once после завершения шагов пост-компиляции.

Прямо сейчас использование этой функции MultiConfiguration приводит к тому, что каждый шаг в вашем рецепте сборки повторяется для каждой комбинации (обычно BuildPlatform и BuildConfiguration).

Есть ли способ применить MultiConfiguration только к шагам сборки Visual Studio? Думаю, в качестве запасного варианта мы можем просто не использовать MultiConfiguration и добавить шаг сборки Visual Studio для каждой комбинации BuildPlatform и BuildConfiguration. Хотя это как-то подло.


azure-pipelines multi-configuration tfs-2015 tfsbuild
person Keith Hill    schedule 29.04.2016    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Что ж, вы можете увидеть расширить описание в разделе Мультиконфигурация: создание нескольких конфигураций с одинаковыми шагами.

введите здесь описание изображения

Таким образом, либо добавить настраиваемый шаг с многократной сборкой, либо не добавлять шаг. На данный момент вам, возможно, придется использовать запасной вариант, который вы упомянули в вопросе.

Если вы считаете, что это необходимая функция, вы можете добавить это в uservoice. Администратор TFS и PM любезно рассмотрят его.

Голос пользователя: https://visualstudio.uservoice.com/forums/330519-team-services< /а>

person PatrickLu-MSFT    schedule 03.05.2016
comment
Дело в том, что я хочу, чтобы матрица платформы/конфигурации сборки применялась к некоторым шагам, таким как сборка Visual Studio, но некоторые шаги, такие как сценарий PowerShell для запуска InstallShield, должны быть одноразовыми, что происходит после всех всех платформ/ были построены комбинации конфигураций. Благодаря ссылке на uservoice. Я отправлю что-нибудь туда, а также через нашего представителя по работе с клиентами. - person Keith Hill; 03.05.2016

arrow_upward
1
arrow_downward

В настоящее время это невозможно. MultiConfiguration всегда строит все шаги.

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

Уже сегодня можно продолжить процесс сборки в Release Definition. Рассматривая первую стадию выпуска как момент времени для «завершения» шагов сборки, вы можете запустить дополнительные шаги, когда будут завершены параллельные шаги.

Это не идеально, но это то, что доступно сегодня.

person jessehouwing    schedule 03.05.2016
comment
Я был бы рад установить флажок на каждом шаге, как у нас для параметров управления, который говорит «Применить мультиконфигурацию» или что-то в этом роде. Черт возьми, этот флажок, вероятно, мог бы быть даже в разделе «Параметры управления». - person Keith Hill; 03.05.2016
comment
Нет такого варианта. Помните, что при распараллеливании эти сборки фактически выполняются на нескольких серверах в разных рабочих областях. Не будет только одного места для сбора результатов. - person jessehouwing; 04.05.2016
comment
Но логически это единая сборка. Я хочу, чтобы результаты/покрытие моих тестов были связаны с этой сборкой. Шаблон сборки XAML делает это тривиальным. Мне трудно поверить, что это не обычный пользовательский сценарий, когда вы хотите собрать/протестировать свой код в различных комбинациях платформы и конфигурации, но вам нужно выполнить шаги, чтобы упаковать все эти двоичные файлы в файл ZIP или MSI. Я был бы совершенно доволен ограничением, что это будет поддерживать параллельные сборки только на одной и той же машине. Это не должно представлять проблемы. - person Keith Hill; 04.05.2016
comment
FWIW, мы не можем использовать функцию фермы, потому что наши сборки, как правило, используют лицензионное программное обеспечение, и мы не хотим выкладывать $$ за больше лицензий, чем нам нужно. Даже если бы мы были готовы платить, некоторые из этих пакетов не поддерживают параллельное управление версиями, что создает проблему. Таким образом, для подавляющего большинства наших сборок в первую очередь требуется Agent.ComputerName. Это также оказывается полезным для устранения неполадок при сборке на машине сборки, потому что мы знаем, к какой машине сборки подключаться по протоколу RDP. Глядя на сборку команды 3-го поколения, мне действительно интересно, достаточно ли MS собрала требования от своих локальных клиентов. - person Keith Hill; 04.05.2016
comment
Один последний комментарий, извините, если кажется, что я сбрасываю вас. Я нет, и я ценю ваш ответ и ответы! Я просто немного разочарован функциями, которые я теряю из gen2. Большинство из них я могу обойти, но обходные пути делают рецепты сборки излишне повторяющимися. У меня есть один с 8 шагами VS Build и 4 шагами VS Test, потому что я не могу использовать мультиконфигурацию. :-( - person Keith Hill; 04.05.2016
comment
Я чувствую твою боль. Отправьте отзыв о Connect, голосовом пользователе и репозитории vso-agent-tasks на GitHub. - person jessehouwing; 04.05.2016
comment
Я отправил несколько элементов на UserVoice — visualstudio.uservoice.com/forums/330519-team-services/ и visualstudio.uservoice.com/forums/330519-team-services/ - person Keith Hill; 05.05.2016