Гранулярность для выбора определения сборки TFS
Я не знаю много о TFS за исключением того, что я использую его. Однако, когда я строю с использованием Pending Changes, наша команда сборки каким-то образом сумела сообщить TFS, что в зависимости от того, какая часть кода редактируется, какие определения сборки доступны для выбора.
Как они это делают? Я не могу найти это эффективно. И до какой степени детализации это можно расширить? В кажущемся несвязанном разделе кода есть один файл, который имеет больше последствий, чем ожидалось, поэтому я бы хотел ограничить возврат файлов более широким определением сборки.
1 ответ
Определение сборки имеет набор сопоставлений управления исходным кодом, которые определяют, какие папки нужны сборке при ее запуске. Этот же набор папок используется Team Build для обоснованного предположения о том, следует ли показывать сборку. Если ожидающие изменения выходят за пределы сопоставлений контроля исходного кода, сборка не будет указана.
Смотрите: Укажите триггеры сборки и причины
Если вы определяете сборку с помощью триггера Continuous Integration, сборка ставится в очередь каждый раз, когда член команды проверяет изменение. Определение сборки Рабочая область определяет, какие файлы инициируют определение сборки. Для получения дополнительной информации о рабочих пространствах сборки см. Работа с рабочими пространствами сборки.