Блог

У нас есть единственное решение, на котором мы хотим начать выполнять gated check-ins. Самая большая проблема, с которой мы сталкиваемся, заключается в том, что мы хотим, чтобы агенты сборки создавали все конфигурации и платформы (ASCII и Unicode на 32 и 64 разрядных версиях) для проверки изменений.
Мы могли бы сделать это с помощью одного агента сборки и запускать их последовательно, но для непрерывной интеграции потребуется слишком много времени, так что это не вариант.

У нас могло бы быть 4 разных определения сборки, которые были бы основаны на 4 разных агентах, но мы все равно не видим, чтобы закрытая сборка запускала 4 разных определения сборки в закрытой сборке.

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

Кто-нибудь знает способ сделать это?

Спасибо

Вы должны уметь распараллеливать сборки с gated check-in, используя шаблон параллельной сборки — смотрите подробное описание в блоге Джима Лэмба.

Обратите внимание, что при использовании этого с gated check-in существует потенциальная «ошибка»: по умолчанию Team Foundation Server получает эксклюзивную блокировку (check-out) при переносе изменений в двоичные файлы. Когда шаблон параллельной сборки выполняется как часть gated check-in, он снимет с полки ваш checkin shelveset для нескольких агентов сборки. Это приведет к сбою, если у вас есть двоичные файлы как часть gated check-in.

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