Teamcity build agent

TeamCity – интеллектуальный сервер непрерывной интеграции

TeamCity — это многофункциональный сервер непрерывной интеграции, готовый к работе сразу же после установки. Он поддерживает множество систем контроля версий, аутентификации, сборки и тестирования прямо из коробки. При этом TeamCity легко расширяем: для многих операций вам даже не нужно знать Java.

Ключевые возможности

  • Мгновенные уведомления об ошибках сборки. Вам не нужно дожидаться окончания сборки, чтобы узнать о проблемах компиляции или упавших тестах
  • Возможность запускать сборку и тестирование измененного кода без коммита в систему контроля версий, прямо из IDE
  • Пожалуй, лучшая на рынке поддежка Java и .NET проектов со встроенными идентификацией структуры проекта и тестов, анализом кода, покрытием кода и интеграцией с Maven и NuGet репозиториями
  • Великолепная встроенная поддержка Ruby и XCode проектов
  • Иерархическая структура проектов, позволяющая легко настроить права и значительно ускоряющая конфигурацию сервера
  • Богатые статистические отчеты по результатам сборок удовлетворят самого требовательного пользователя
  • Легкое управление фермой билд-агентов, включая их автоматическое обновление, разбиение на пулы и отчеты по загрузке
  • Управление общими ресурсами, позволяющее без проблем ограничивать доступ к совместно используемым базам данных, тестовым устройствам и т.п.
  • Конфигурируемые условия падения сборки на основе множества метрик, включая такие как число упавших тестов, число непокрытых классов и модулей, а также метрики, исключающие деградацию качества кода
  • Уникальные функции по поддержке сервера в хорошей форме: встроенная очистка истории сборок, отчеты о занимаемом дисковом пространстве и отчеты о здоровье сервера
  • Поддержка смешанной аутентификации, позволяющая использовать различные способы аутентификации (LDAP, Windows Domain, встроенная) одновременно
  • Отличная интеграция с системами контроля версий: поддержка множества систем для одного проекта, feature branches для Mercurial и Git, продвинутые правила для запуска сборок на основе изменений в системах контроля версий
  • Роли и группы пользователей, позволяющие быстро и легко настроить доступ к серверу для всех пользователей компании
  • Поддержка сервисных сообщений, позволяющих инструментам сборки напрямую общаться с сервером, и REST API, дающий возможность управлять сервером, используя сторонние скрипты
  • Более 100 бесплатных готовых к использованию плагинов

Что нового

  • Иерархическая структура проектов
  • Новые средства управления инфраструктурой сборок: здоровье сервера, использование диска и улучшенная очистка
  • Meta-Runner — новый способ упростить настройку и сократить число шагов сборки
  • Встроенный компилятор IntelliJ IDEA с поддержкой языков Scala, Groovy, Clojure, Kotlin и Android-проектов
  • Поддержка смешанной аутентификации, позволяющая использовать различные способы аутентификации (LDAP, Windows Domain, встроенная) одновременно
  • Встроенный плагин для совместного использования ресурсов, позволяющий ограничить использование важных ресурсов
  • Новые функции для работы с ошибками сборки (обнаружение новых/исправленных ошибок, их исследование и игнорирование)

Задачка дня : имеем более чем 2-3 разработчика, проект игры на Unity и необходимость получать автоматически «установочные файлы» приложения под разные платформы. «Можно подключить к компьютеру устройство запустить эмулятор и не нужен мне ваш TeamCity» — но так же в команде есть тестировщик, который не должен запариваться со всеми IDE и прочими вещами,а лишь получать и проверять, проверять, проверять, и именно поэтому необходимо настроить процесс получения готовых билдов под разные платформы автоматически. Итоговая формула входных данных : Unity игра + VCS(gitmercurial) + 2 + разработчика + 1 + тестировщик + дополнительные менеджеры заказчик. Решения данной задачи берет на себя такой подход как CI (Continuous Integrationннепрерывная интеграция) — подход позволяет обеспечить автоматическое выполнение задач проекта(тестирование, получение сборки, отправка уведомлений, отправка готового файла сборки в хранилище и тд.), а инструмент для выполнения — TeamCity (TC далее). Причины выбора и анализ аналогов не привожу, так как это тема отдельной статьи. На официальном сайте создателей инструмента  JetBrains можно увидеть достаточно много обширной информации по TC, а так же получить пробник на 60 дней. Описание установки и настройки TC так же не привожу, потому, как пути решения вопросов и проблем возникающих при установке уже лежат там где и должны.

Общая схема иерархии и взаимодействия компонентов в системе такова:

Project — проект который и является базой. Build configuration — логическая единица настроекшагов, которые обеспечивают группировку по критериям (платформаразные источники исходного кода). Build step — шаг автоматического исполнения, в котором указываются инструкции для выполнения. Build trigger — триггер, который будет срабатывать при заданных условиях.

Исходя из данной схемы, для начала необходимо создать проект, настроить build configuration,  подключить VCS (Version Control System — система управления версиями) и составить  build steps. Проект создали, указали все нужные поля, создание конфигурации не содержит никаких сложностей, так как это чисто логическая единица:

К конфигурации необходимо подключить источник VCS, где все исходники проекта содержатся:

Type of VCS — в нашем примере Mercurial. VCS root name, VCS root ID — уникальное имя для идентификации VCS источника. Pull changes from — источник исходного кода. Default branch — какую ветку в системе контроля версий использовать. Имя пользователя и пароль — те, что используете в системе VCS. После создания конфигурации и подключения источника VCS необходимо создать build steps, которые будут выполнять всю рутину автоматических задач:

Runner type  — список плагинов, которые доступны в TC и которые можно использовать.

Предоставлено очень много вариаций под самые разные задачи, если ваша задача не решается, то можно написать собственный плагин, используя Java платформу. Таким образом, на высоком уровне проявляется новая схема взаимодействия компонентов в TC — все задачи выполняют плагины(runners), остается только написать скрипт, который и будет выполнятся. Для различных runner’ов разные настройки, к примеру для MSBuild следующие:

Build step’ов мы можем добавлять сколько нам необходимо в рамках нашей задачи, так же можем ограничивать выполнение — если предыдущий step не выполнен, то данный тоже не запускать. Для получения билдов из Unity проекта необходимы следующие setep’ы : построение проекта специфической платформы (для примера Windows Phone 8), получение исполняемого файла, перемещение файла в необходимый каталог сервер. Построение проекта под необходимую платформу из Unity источника:

Но данный скрипт необходимо запустить на выполнение, для этого воспользуемся runner’ом MSBuild и создадим для него скрипт, который и будет использовать Unity IDE в консольном режиме и запустит на выполнение msbuild скрипт:

Отмечу, что в данном скрипте используются параметры : $(MSBuildProjectDirectory) — указывает каталог проекта (рабочая папка),  и $(UnityPath) — указывает путь к Unity.exe. -batchmode -executeMethod BuildScript.BuildWindowsPhone8 данные параметры указывают что Unity мы запускаем в «консольном» режиме и выполняем указанный метод в указанном скрипте.

На данном этапе необходимо дополнительно разъяснить архитектурную особенность TC. На высоком уровне сервер(сайтхост) TC хранит все настройки автоматизации по различным проектам, выполнятся все эти настройки и скрипты будут на агентах — локальных машинах. Агент — любой компьютер, который подключается к системе TC и если удовлетворяет критериям (список доступных средств IDE утилит и инструментов), то выполняет всю автоматизацию. Каждый агент имеет свою рабочую папку для проекта, место в которое агент выкачивает обновления исходных кодов из VCS и после уже использует для работы. Таким образом, если агент имеет копию проекта в которой и будут все изменения от TC. К одному проекту можно подключить множество агентов, и если какой-либо будет отключен, то будет использован автоматически следующий по списку. Так же агент может иметь локальные параметры, которые будут доступны в TC, остается в настройках build step использовать только переменную. Так же таким образом можно указать отличительные особенности вашего агента (установлена специальная утилита доступны особенные инструменты). Для изменения параметров агентов необходимо отредактировать файл  *Директория билд агента*confbuildAgent.properties где можно указать, к примеру путь к Unity.exe  env.Unity4=E:\Program\Unity4\Editor\Unity.exe. Использование данной переменной и остальные настройки MSBuild указаны ниже:

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

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

.

Добавить комментарий

Закрыть меню