Сборка проектов .NET с помощью TeamCity

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

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

Рекомендуется иметь общее представление о .NET и .NET CLI. For more information, see the Getting Started guide in the .NET 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/matkoch/teamcity-dotnet.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 в других системах непрерывной интеграции часто называются заданиями (jobs). Пока что можно использовать название конфигурации сборки по умолчанию — Build.

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

Если TeamCity находит в репозитории файл решения (*.sln), то автоматически предлагает необходимые шаги сборки для вашего проекта. Сюда входит компиляция решения .NET с помощью dotnet build и выполнение всех тестов с помощью dotnet test.

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

Установите флажки для нужных шагов сборки .NET и нажмите Use selected.

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

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

Теперь можно запустить первую сборку. Нажмите кнопку Run в правом верхнем углу, как показано ниже.

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

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

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

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

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

После подключения репозитория .NET к 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 будет отслеживать все ветки, соответствующие введенной спецификации и отправленные в репозиторий. При обнаружении изменений будет запущена сборка.

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

If you want TeamCity to automatically build pull requests that are made against your repository, you can add the Pull Request build feature to your build configuration.

  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 (появится соответствующий значок).