Сборка и тестирование проектов Java с помощью Maven

В руководстве описан порядок сборки проектов Java и Maven с помощью TeamCity. Оно будет полезно разработчикам, никогда ранее не работавшим с TeamCity.

Предварительные условия

Рекомендуется иметь общее представление о Java и фреймворке Maven. For more information, see the Getting Started with Maven guide in the Maven documentation.

Шаг 1. Создание проекта в TeamCity

  1. Нажмите на значок Administration в виде гайки в правом верхнем углу страницы TeamCity.
  2. Нажмите + Create Project и выберите вкладку From a repository URL. In the Repository URL field, enter your repository, for example: https://github.com/marcobehlerjetbrains/maven.git. TeamCity предлагает встроенную поддержку всех популярных систем контроля версий: Git, Subversion, Mercurial, Perforce и TFS (как в облачной, так и в локальной версии TeamCity). Поддержка CVS, StarTeam и Visual SourceSafe есть только в локальной версии TeamCity.
  3. Если репозиторий использует аутентификацию, введите имя пользователя и пароль или токен доступа.
  4. Нажмите Proceed.

Если TeamCity успешно подключился к репозиторию, появится следующее окно.

В окне Create Project From URL можно изменить название проекта и название первоначальной конфигурации сборки.

Примечание: в новых версиях появились также поля Default branch и Branch specification, которые позволяют указать, какие именно ветки должен создавать TeamCity. На этом этапе их можно игнорировать.

  • TeamCity предложит название проекта по умолчанию, но вы можете ввести другое, более подходящее.
  • TeamCity предложит также название конфигурации сборки по умолчанию. Можно оставить предложенное название, при необходимости вы сможете изменить его позже. (Каждый проект TeamCity включает в себя по крайней мере одну конфигурацию сборки, которая содержит все необходимые шаги для создания проекта. Конфигурации сборок TeamCity в других системах непрерывной интеграции часто называются заданиями (jobs).)
  • Нажмите Proceed.

Когда вы нажали Proceed, TeamCity автоматически сканирует репозиторий контроля версий в поисках поддерживаемых технологий, в данном случае — Java и Maven.

Если TeamCity находит в репозитории файл pom.xml, то автоматически предлагает необходимый шаг сборки для вашего проекта. Этот шаг включает в себя компиляцию проекта Maven и выполнение всех тестов с помощью mvn clean test.

Не путайте шаги сборки с конфигурацией сборки. Конфигурация сборки может содержать много шагов.

  1. Поставьте флажок рядом с шагом сборки Maven.
  2. Нажмите Use selected.

Вы успешно настроили репозиторий Maven для работы с TeamCity:

Шаг 2. Запуск первой сборки

Теперь можно запустить первую сборку.

  1. Нажмите кнопку Run в правом верхнем углу окна, как показано ниже:

Примечание: если вы используете TeamCity Cloud, билд-агент может стать доступным через пару минут. В течение этого времени сборка находится в очереди, пока ее не подхватит доступный агент.

Если вы используете локальную версию TeamCity с локальными билд-агентами, сборка начнется сразу.

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

Шаг 3. Настройка проекта Maven в TeamCity

После подключения репозитория Maven к TeamCity можно продолжать разработку и отправлять код в репозиторий.

По умолчанию TeamCity каждые 60 секунд отправляет в основную (main) ветку репозитория системы контроля версий VCS запросы относительно внесенных изменений и запускает единую сборку для всех обнаруженных коммитов.

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

Если вы хотите запускать сборку для каждого изменения в любой ветке репозитория, а не только в main, добавьте спецификацию веток с использованием символов подстановки в настройки корня VCS. Обратите внимание: настройки VCS сохраняются для всего проекта TeamCity, а не для конкретной конфигурации сборки. Таким образом, любые внесенные изменения будут применены ко всем конфигурациям сборки, использующим тот же корень VCS.

  1. На странице общей информации о проекте нажмите Edit Project. Если у вас открыта конфигурация сборки Build, можно также нажать Edit Configuration.
  2. Перейдите к VCS Roots (системы контроля версий) и измените корень VCS.
  3. Заполните поле Branch Specification и нажмите Save. Если вы не видите поле Branch Specification, нажмите сначала Show Advanced.

Примеры спецификации ветки:

  • +:refs/heads/* — TeamCity будет проверять наличие изменений во всех ветках проектов, но не будет проверять пул-реквесты на таких платформах, как GitHub, потому что они соответствуют refs/pull/*;
  • +:* — TeamCity будет проверять наличие любых внесенных изменений во всех ветках;
  • ваша собственная спецификация веток.

Теперь TeamCity будет отслеживать все ветки, соответствующие введенной спецификации и отправленные в репозиторий. При обнаружении изменений будет запущена сборка.

Генерация сборок из пул-реквестов

Если вы хотите, чтобы TeamCity автоматически создавал сборки из пул-реквестов, отправляемых в репозиторий, можно добавить в конфигурацию сборки функцию Pull Request.

  1. Откройте конфигурацию сборки и нажмите Edit Configuration.
  2. Перейдите к Build Features и нажмите Add Build Feature. Если вы не видите ссылку Build Features, нажмите Show More.
  3. В раскрывающемся списке выберите Pull Requests, а затем выберите свой репозиторий и поставщика услуг репозитория (GitHub, GitLab и т. п.).
  4. При необходимости можно использовать Pull Request Filtering, чтобы отфильтровать пул-реквесты по автору или названию ветки.

Примечание: функция сборки Pull Request прозрачно расширяет спецификацию ветки (подробнее см. предыдущий шаг). Например, при использовании GitHub функция пул-реквеста (незаметно) добавляет к спецификации ветки +:refs/pull/*.

Если используется функция пул-реквестов, рекомендуем убедиться, что ветки пул-реквестов не включены в общую спецификацию ветки явным образом. В противном случае возможности, связанные с пул-реквестами, будут недоступны в TeamCity.

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

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

Commit Status Publisher

When using the pull requests feature in combination with Azure DevOps, Bitbucket Server, GitHub, or GitLab, it also makes sense to use the Commit Status Publisher build feature. Она изменяет статус пул-реквеста на соответствующей платформе в зависимости от результатов сборки.

Чтобы настроить отправку результатов сборки из TeamCity обратно в GitHub, нужно сделать следующее:

  1. Откройте конфигурацию сборки и нажмите Edit Configuration.
  2. Перейдите к Build Features и нажмите Add Build Feature.
  3. Выберите в раскрывающемся списке Commit Status Publisher, затем выберите репозиторий и издателя (GitHub, GitLab и т. п.).
  4. Укажите токен доступа с правами, позволяющими публиковать статус коммита.
  5. Нажмите Save.

Когда TeamCity запустит сборку, вы сразу увидите, привели ли внесенные изменения к ошибке в сборке, прямо на вкладке Pull Request в GitHub (появится соответствующий значок). Кроме того, отображается ссылка на сервер TeamCity, так что вы можете посмотреть результаты тестирования.