Развертывание и настройка агентов сборки

Чтобы использовать Team Foundation Build, команда должна иметь по крайней мере один агент сборки для выполнения ресурсозатратных операций в процессе сборки.

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

Агент сборки выполняет операции процесса сборки, входящие в действии AgentScope. К таким операциям относятся получение файлов из системы управления версиями, подготовка рабочей области, компиляция кода, выполнение тестов и слияние файлов обратно в систему управления версиями.

Убедитесь, что сервер сборки, на котором размещены агенты сборки, имеет достаточные ресурсы памяти и возможности обработки, соответствующие размеру и сложности базы кода и тестов в коллекции командных проектов. Обычно не следует размещать более одного агента сборки на каждое процессорное ядро сервера сборки. Можно также повысить производительность, выделив один физический жесткий диск рабочему каталогу каждого агента сборки.

Необходимые разрешения

Вы должны быть членом группы "Администраторы Windows" на сервере сборки и членом группы "Администраторы сборок коллекции проектов" в коллекции командных проектов. См. раздел Справочник по разрешениям Team Foundation Server.

Выберите действие.

• Создание или изменение агента сборки

• Установка Visual Studio и другого программного обеспечения для включения компиляции и других возможностей

• Задание рабочего каталога

• Включение агента сборки для выполнения тестов

• Назначение тегов для представления возможностей агента сборки или целей

• Развертывание агента сборки, который может компилировать и тестировать приложение для Магазина Windows

• Удаление агента сборки

Создание или изменение агента сборки

Создание или изменение агента сборки с сервера сборки

1. Войдите в систему сервера сборки, который требуется настроить.

2. Из меню "Пуск" Windows запустите Консоль администрирования Team Foundation.

   Отобразится окно Консоль администрирования Team Foundation.

3. В области дерева консоли администрирования Team Foundation разверните имя сервера и выберите узел Конфигурация сборки.

   В области содержимого появятся сведения о сервере сборки.

   Если отображается сообщение Настройка установленных компонентов, обратитесь к разделу Развертывание сервера сборки.

4. На странице "Конфигурация сборки":

   • Чтобы создать новый агент сборки, выберите команду Создать агент.

   • Чтобы изменить существующий агент сборки,

     

     выберите Свойства.

   Появится диалоговое окно Свойства агента построения.

Изменение агента сборки из Visual Studio

1. В Visual Studio в Team Explorer:

   1. Если вы еще не подключены к командному проекту из коллекции командных проектов, подключитесь к командному проекту.

   2. Выберите Главная, а затем выберите Сборки.

2. На странице "Сборки" выберите Действия, а затем — Управление контроллерами сборки.

   На экране появится диалоговое окно Управление контроллерами построений.

   

3. Выберите агент сборки, который требуется изменить, и щелкните Свойства.

   Появится диалоговое окно Свойства агента сборки.

Отображаемое имя, Описание. Введите имя и описание, чтобы члены команды могли легко определить агент сборки.

Контроллер. Выберите контроллер сборок, который должен управлять этим агентом сборки. Контроллер сборок может работать на том же сервере сборки, что и этот агент сборки, или на другом сервере сборки.

В разделах ниже содержатся дополнительные сведения о настройке агента сборки.

Установка Visual Studio и другого программного обеспечения для включения компиляции и других возможностей

На агенте сборки необходимо установить версию Visual Studio, используемую вашей командой на компьютерах разработки. См. раздел Установка Visual Studio. Установите также любое другое программное обеспечение и компоненты, которые установлены на компьютерах разработки и требуются для сборки приложения.

Задание рабочего каталога

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

Использование токенов рабочего каталога

Хотя для свойства Рабочий каталог путь можно задать в буквенном представлении (например, c:\temp\build\), более простой и надежный подход — задание пути с помощью токенов. Можно использовать два вида токенов:

• Переменные среды
  Переменные среды содержат сведения о среде для системы и пользователя, вошедшего в систему. Самая обычная переменная — SYSTEMDRIVE, однако в некоторых случаях могут также использоваться такие переменные, как USERNAME или HOMEPATH.

  Совет

  Чтобы вывести список переменных среды на сервере сборки, откройте командную строку и введите set.

• Переменные Team Foundation Build
  В рабочем каталоге агента сборки можно использовать следующие переменные:

  • $(BuildAgentId) — автоматически генерируемое целое число, являющееся уникальным идентификатором агента построения в коллекции командного проекта.

  • $(BuildAgentName) — Отображаемое имя агента построения.

  • $(BuildDefinitionId) — автоматически генерируемое целое число, являющееся уникальным идентификатором определения построения в коллекции командного проекта.

  • $(BuildDefinitionPath) — имя командного проекта и имя определения построения, разделенные обратной косой чертой.

Пример рабочего каталога

Например, имеем агента построения с именем BuildBot3. В командном проекте CoolApp определены два построения с именами NightlyBuild и WeeklyBuild. В поле Рабочая папка укажите значение $(SystemDrive)\TeamBuilds\$(BuildAgentName)\$(BuildDefinitionPath). В результате, агент построения BuildBot3 создает и использует две рабочих папки, а именно:

C:\TeamBuilds\BuildBot3\CoolApp\NightlyBuild

C:\ TeamBuilds\BuildBot3\CoolApp\WeeklyBuild

Длина пути к рабочему каталогу

При выборе рабочей папки необходимо учитывать, что пути к этой папке, формируемые агентом построения, не должны превышать 259 символов. В противном случае возможен сбой сборок с вводом в журнал следующей ошибки: TF10128: The path PhysicalPath contains more than the allowed 259 characters. Type or select a shorter path.

Чтобы решить эту проблему, можно указать рабочий каталог, физический путь к которому короче. Например, можно указать $(HOMEDRIVE)\bld\$(BuildAgentID)\$(BuildDefinitionID), в результате чего рабочий каталог будет следующим: c:\bld\3\2\.

Подкаталоги, создаваемые в рабочем каталоге

Агент построения создает следующие подкаталоги по такому пути и работает в них.

Включение агента сборки для выполнения тестов

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

Агент сборки может выполнять:

• Покрытие кода

• Кодированные тесты ИП (требуется сервер сборки, работающий в интерактивном режиме. См. разделы Запуск сервера сборки в интерактивном режиме и Проверка кода с помощью модели автоматизации пользовательского интерфейса.)

• Создание данных для теста базы данных

• Модульные тесты базы данных.

• Обычные тесты

• Нагрузочные тесты

• Модульные тесты

• Упорядоченные тесты

• Анализ влияния на тест

• Веб-тесты

Назначение тегов для представления возможностей агента сборки или целей

С увеличением масштаба системы сборки может потребоваться определить специализированные агенты сборки. Если у агента построения есть специальные возможности или он предназначен для особого использования, этому агенту следует назначить один или несколько тегов. В таком случае, при создании участником команды определения построения, для которого требуется определенный вид агента построения, он может указать тег в определении построения.

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

В следующей таблице приведены примеры имен тегов и возможности агента построения, которые они представляют.

К агенту построения можно применить более одного тега. Например, можно создать агента построения с тегами x86 и выпуск, чтобы указать агента, установленного для компиляции конфигурации выпуска 32-разрядного приложения.

При запуске нескольких агентов сборки на одном сервере сборки все они, вероятно, будут иметь одинаковые возможности. Поэтому может возникнуть необходимость в применении одинаковых тегов ко всем агентам сборки на одном сервере сборки.

Удаление агента сборки

1. В Visual Studio откройте диалоговое окно Управление контроллерами сборки, как описано выше в разделе Создание или изменение агента сборки.

2. Выберите агент сборки, который требуется удалить, и нажмите кнопку Удалить.

Следующие шаги

• Масштабирование системы Team Foundation Build
  По мере увеличения численности рабочей группы и базы кода можно относительно легко наращивать систему сборки.

• Управление системой сборки.
  Иногда необходимо отслеживать систему сборки и управлять ею.

• Использование системы сборки для компиляции, тестирования и развертывания приложения
  После размещения системы сборки команда готова к созданию простого процесса сборки (например, сборки с непрерывной интеграцией) и использованию возможностей автоматизированной сборки и тестирования приложения.