Использование teamcity с xamarin

Переиспользование результатов сборки

Еще один способ оптимизировать пайплайн — переиспользование артефактов. Допустим, цепочка сборки успешно завершилась и мы запустили ее снова (или она сама запустилась по какой-либо причине), но на этот раз TeamCity будет немного хитрее.

Что, если мы не будем пересобирать конфигурацию зависимости в цепочки, если никаких изменений в кодовой базе не было? Действительно, возвращаясь к нашему примеру, вряд ли нужно каждый раз собирать apk на Development, если на самом деле там ничего не изменилось.

К счастью, чтобы все работало именно так, не нужно ничего делать: все работает прямо «из коробки». Но мы можем ее отключить.

Заходим в Build Configuration Home нашего Bishop-scan:

Нажимаем на многоточие, которое находится рядом с Run. В появившемся окне переходим на вкладку Dependencies, нас интересует настройка Rebuild snapshot dependencies:

Нажимаем Run Build, и вуаля — теперь TC заново соберет артефакты в цепочке, даже если не было никаких изменений в кодовой базе.

Установка агента

Для сборки кода на удаленной системе, нам необходимо установить на нее агента Teamcity. Мы рассмотрим инструкцию для его развертывания на Linux — Ubuntu, Debian, CentOS.

Сначала установим утилиты, которые нам понадобятся для выполнения установки.

а) Для Ubuntu / Debian:

apt-get install wget unzip default-jdk

б) Для CentOS:

yum install wget unzip java-11-openjdk-devel

* где:

wget — утилита для загрузки файлов из сети по http.
unzip — программа для распаковки zip-архивов.
default-jdk/java-11-openjdk-devel — реализация java.

Скачиваем архив с агентом с нашего сервера:

wget http://192.168.1.15:8111/update/buildAgent.zip

* где 192.168.1.15 — это адрес нашего сервера.
* если мы получим сообщение об ошибке, что команда wget не найдена, необходимо установить одноименную утилиту — yum install wget или apt-get install wget.

Распакуем архив в каталог /opt/teamcity-agent:

unzip buildAgent.zip -d /opt/teamcity-agent

Копируем шаблонный файл с конфигурацией:

cp /opt/teamcity-agent/conf/buildAgent.dist.properties /opt/teamcity-agent/conf/buildAgent.properties

Агент готов к работе. Теперь создадим юнит в systemd для его запуска:

vi /etc/systemd/system/teamcity-agent.service

Description=TeamCity Build Agent
After=network.target

Type=forking
PIDFile=/opt/teamcity-agent/logs/buildAgent.pid
ExecStart=/opt/teamcity-agent/bin/agent.sh start
ExecStop=/opt/teamcity-agent/bin/agent.sh stop

WantedBy=multi-user.target

Перечитываем конфигурацию systemd:

systemctl daemon-reload

Разрешаем автозапуск агента teamcity и стартуем его:

systemctl enable teamcity-agent —now

Проверить состояние выполнения можно командой:

systemctl status teamcity-agent

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

vi /opt/teamcity-agent/conf/buildAgent.properties

Вставляем строку:

ownPort=9088

* в данном примере мы хотим запустить агента на порту 9088.

Перезагружаем сервис:

systemctl restart teamcity-agent

Аутентификация через GitHub, GitLab и Bitbucket

Мы стремимся к тому, чтобы непрерывная интеграция стала привычным и естественным процессом в жизни разработчиков. Чтобы охватить больше сценариев использования, TeamCity теперь поддерживает аутентификацию через внешние сервисы: GitHub, GitLab и Bitbucket.

TeamCity 2020.2 мгновенно сопоставит аккаунты в другом сервисе с существующими пользователями в системе и позволит начать работу без необходимости вводить пароль. TeamCity интегрируется с каталогами пользователей поддерживаемых сервисов, например организациями в GitHub и группами в GitLab, и может автоматически создавать профили, когда к вашей команде присоединяются новые участники.

Помимо облачных сервисов, TeamCity 2020.2 поддерживает локальные версии GitHub (GitHub Enterprise) и GitLab (GitLab self-hosted).

Pipeline

Здесь все довольно просто. Пайплайн — это некоторый (последовательный) набор действий, совершаемых во время сборки. И хотя пайплайн — это классическое определение для процессов, происходящих на CI/CD, нигде — ни в документации TeamCity, ни в веб-интерфейсе — ты не встретишь это слово.

Дело в том, что у TC есть собственный термин — build chain, цепочка сборки. Цепочка сборки в TeamCity представляет собой направленный ациклический граф, поэтому пайплайн, подразумевающий последовательное выполнение шагов, — лишь частный случай цепочки сборки из TC.

Пример направленного ациклического графа

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

Создание Project TeamCity

после установки TeamCity и Visual Studio для Mac может выполнить сборку проекта, пора создать проект в TeamCity для сборки проекта и отправки его в центр приложений.

Для начала Войдите в TeamCity через веб-браузер. Перейдите к корневой Project:

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

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

. .

Если проект VCS не создан, его можно создать на странице новой корневой папки VCS, как показано ниже.

, ».

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

. на . Пример настройки триггера сборки можно увидеть на следующем снимке экрана:

.
В предыдущем разделе параметризация скрипта сборки было предложено сохранить некоторые значения в виде переменных среды. Эти переменные можно добавить в конфигурацию сборки с помощью экрана «Параметры». Добавьте переменные для ключа APIцентра приложений, идентификатор устройства iOS и идентификатор устройства Android, как показано на снимке экрана ниже:

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

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

Управление сборкой проектов вместе с teamcity. Часть 3

August 3, 2009

http://sourceforge.net/projects/filezilla/

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0http://maven.apache.org/maven-v4_0_0.xsd">

```
 <modelVersion>4.0.0</modelVersion>
```
```
 <groupId>blackzorro</groupId>
```
```
 <artifactId>testartifact1</artifactId>
```
```
 <packaging>jar</packaging>
```
```
 <version>1.0</version>
```
```
 <name>Simple Maven 2 Artifact</name>
```
```
 <url>http://maven.apache.org</url>
```
```
 <dependencies>
```
```
    <dependency>
```
```
    <groupId>junit</groupId>
```
```
    <artifactId>junit</artifactId>
```
```
    <version>4.4</version>
```
```
    <scope>test</scope>
```
```
   </dependency>
```
```
 </dependencies>
```
```
 <build>
```
```
  <plugins>
```
```
   <plugin>
```

    <artifactId>maven-compiler-plugin</artifactId>

```
    <configuration>
```
```
       < source >1.5< / source >
```
```
       <target>1.5</target>
```
```
     </configuration>
```
```
   </plugin>
```
```
  </plugins>
```
```
  <extensions>
```
```
    <extension>
```

     <groupId>org.apache.maven.wagon</groupId>

```
     <artifactId>wagon-ftp</artifactId>
```
```
     <version>1.0-alpha-6</version>
```
```
   </extension>
```
```
  </extensions>
```
```
 </build>
```
```
  
```
```
 <distributionManagement>
```
```
   <repository>
```
```
     <id>ftp-repository</id>
```
```
     <url>ftp://center/m2-repo</url>
```
```
     <layout>default</layout>
```
```
   </repository>
```
```
  </distributionManagement>
```
```
</project>
```

```
<servers>
```
```
  <server>
```
```
   <id>ftp-repository</id>
```
```
   <username>vasyano</username>
```
```
   <password>secret</password>
```
```
  </server>
```
```
</servers>
```

default

```
<version>1.0</version>
```

```
<version>${version.long}</version>
```

```
<properties>
```
```
  <version.short>1.0</version.short>
```

  <version.long>${version.short}B${build.number}</version.long>

```
</properties>
```

```
<profiles>
```
```
 <profile>
```
```
  <id>default-version</id>
```
```
  <activation>
```
```
    <property>
```
```
     <name>!build.number</name>
```
```
   </property>
```
```
  </activation>
```
```
  <properties>
```
```
   <version.long>local</version.long>
```
```
   </properties>
```
```
 </profile>
```
```
</profiles>
```

```
<profile>
```
```
   <id>saveToFtp</id>
```
```
   <build>
```
```
      <plugins>
```
```
         <plugin>
```

            <groupId>org.apache.maven.plugins</groupId>

            <artifactId>maven-antrun-plugin</artifactId>

```
            <version>1.2</version>
```
```
            <dependencies>
```
```
               <dependency>
```

                  <groupId>ant</groupId>

                  <artifactId>ant-commons-net</artifactId>

                  <version>1.6.5</version>

```
               </dependency>
```
```
               <dependency>
```

                  <groupId>commons-net</groupId>

                  <artifactId>commons-net</artifactId>

                  <version>2.0</version>

```
               </dependency>
```
```
            </dependencies>
```
```
            <executions>
```
```
               <execution>
```

                  <phase>package</phase>

```
                  <goals>
```
```
                     <goal>run</goal>
```
```
                  </goals>
```
```
               </execution>
```
```
            </executions>
```
```
            <configuration>
```
```
               <tasks>
```

                  <copy file="target/testartifact1-${version.long}.jar" todir="\\center\SharedDocs\my-app"/>

                  <ftp server="center" binary="true" verbose="true" userid="vasyano" password="secret" remotedir="/">

                     <fileset dir="target">

                        <include name="*.jar"/>

```
                     </fileset>
```
```
                  </ftp>
```
```
               </tasks>
```
```
            </configuration>
```
```
         </plugin>
```
```
      </plugins>
```
```
   </build>
```
```
</profile>
```

target/*.jar
target/surefire-reports/**/*.* => test reports

Build Chains

Наконец-то мы добрались до самих цепочек сборки — build chains.

Как я уже говорил, build chains позволяет разносить шаги сборки по разным конфигурациям, связывая их при помощи снепшот-зависимостей.

То, как TeamCity работает с цепочками сборки, открывает для нас несколько интересных фичей: параллельная сборка конфигураций (круто, да?), переиспользование результатов сборки, синхронизация конфигураций между разными репозиториями. Но самое главное: build chains существенно облегчают поддержку и развитие конфигураций.

Попрактикуемся?

Чтобы создать цепочку сборки, достаточно выбрать две конфигурации сборки и настроить между ними снепшот-зависимость. В качестве примера возьмем две конфигурации:

Одна будет собирать релизный apk-файл с android-приложением мобильного банка для юридических лиц.
Вторая будет отправлять этот apk на сервер Bishop — сервиса для проверки android-приложений на наличие уязвимостей.

Итак, открываем конфигурацию сборки Bishop-scan:

Переходим на вкладку Dependencies и нажимаем кнопку Add new snapshot dependency:

Как видим, кроме snapshot dependency можно добавить artifact dependency, но об этом мы поговорим несколько позже.

В появившемся окне нам предстоит настроить зависимость, указав несколько настроек:

Depend on	Выбираем ту конфигурацию, от которой будет зависеть текущая
Enforce revisions synchronization	Если включить эту опцию, все конфигурации будут работать, используя одни и те же сорсы, и никакие изменения в репозитории, возникшие на момент запуска зависимого билда, не будут браться в расчет
Do not run build if there is a suitable one	С этой опцией TeamCity не будет запускать зависимую сборку, если существует другая запущенная или завершенная подходящая (suitable) сборка. О том, что такое suitable build, мы поговорим чуть позже
Run build on the same agent	TeamCity будет собирать зависимую сборку на том же агенте, на котором собиралась основная сборка
Only use successful builds from suitable ones	Из suitable-билдов будут использоваться только те, которые были завершены без ошибок
On failed dependency/ On failed to start/canceled dependency	Здесь указываем, что делать, если зависимый билд упал: игнорировать, сообщать об ошибке, отменять билд

Нажимаем Save и вуаля — мы успешно построили свой первый build chain!

Полный граф цепочки сборки можно посмотреть, нажав на build chain тут:

Откроется отдельная вкладка, которая визуализирует для нас этот граф:

По графу видно, что перед тем, как мы запустим Bishop-scan, сначала будет собран Development, а только потом запустится Bishop-scan. Круто? Конечно!

Но вот проблема: Development собирает для нас артефакт. Как его использовать в Bishop-scan?

General Settings

Здесь мы видим список обязательных для заполнения полей, а именно:

Name	Уникальное имя конфигурации (например, Development, Upload To Testers, Nightly Builds)
Build Configuration ID	Уникальный ID конфигурации, который можно будет использовать в REST API
Build number format	Каждой сборке TeamCity присваивает свой номер. В этом поле его можно отформатировать. Например, выводить не «1984», а «какая-нибудь-строка-1984»
Artifact paths	После каждой сборки TeamCity может оставлять артефакты (подробнее о них расскажу позже), здесь мы прописываем пути к ним. Например, все, что будет лежать в */build/reports/, TeamCity заберет к себе и сохранит в конфигурации в качестве артефакта. А все, что лежит в rko/build/outputs/apk, TeamCity поместит в отдельную папку apk и также отдаст нам ее содержимое в качестве артефакта

Обзор задач

Чтобы подготавливать и использовать новый командный проект в TFS, необходимо выполнить следующие общие действия:

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

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

В задачах и пошаговых руководствах этого раздела предполагается, что вы установили и настроили TFS и создали коллекцию командных проектов в рамках процесса настройки. Дополнительные сведения об этих допущениях и общие сведения о сценарии см. в статье Настройка сервера сборки TFS для веб-развертывания.

Артефакты

Еще одна интересная фича в TeamCity — артефакты. Это все те файлы, которые были получены в результате сборки: файлы с логами, WAR-файлы и так далее.

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

Представим такой кейс: в проекте есть некий скрипт, который прогоняет ряд lint-проверок. Результаты этих проверок сохраняются в какой-нибудь файл прямо в проекте, допустим в ../build/outputs/lint.

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

Открываем General Settings проекта и находим поле Artifact paths. Прописываем там следующее:

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

Далее нужно добавить шаг сборки, который будет прогонять lint. Настройки этого шага зависят от раннера.

Checkout Rules

Вообще, существует довольно много способов оптимизировать пайплайн. Один из них — настроить правила, по которым TeamCity скачивает репозиторий.

Вернемся к предыдущему примеру: мы сделали так, чтобы любое изменение в Development триггерило Bishop-scan. Но что, если мы не хотим, чтобы изменение в каком-нибудь .gradle-файле влекло за собой полную сборку .apk и анализ ее на серверах Bishop?

Для этого можно правильно настроить Checkout Rules в конфигурации Development.

Открываем Version Control Settings и жмем на Edit checkout rules:

В появившемся окне мы можем, например, исключить папку gradle, в которой лежат все наши .gradle файлы:

Для этого достаточно прописать -:gradle в правилах, и папка gradle будет игнорироваться при мониторинге VCS Root’а.

Передача параметров в шаги сборки

Давайте создадим какой-нибудь параметр внутри конфигурации, которую мы рассматривали ранее, и попробуем передать его в шаг сборки. Открываем вкладку Parameters в настройках конфигурации, нажимаем Add new parameter и заполняем поля:

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

Нажимаем Save, идем на вкладку Build Steps и нажимаем на шаг сборки Hello, World, который создали до этого, и добавляем в скрипт следующее:

Завернув название параметра в “%”, TeamCity сможет обращаться к нему и считывать.

Build Configurations

Мы разобрались, что такое проект, как его «соединять» с системой контроля версий, как добавлять параметры в сборку

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

Каждая сборка, которая была выполнена по заданному сценарию, может иметь два статуса: Success либо Failed

Итак, конфигурация сборки — это набор правил, которые определяют сценарий сборки. Каждая сборка, которая была выполнена по заданному сценарию, может иметь два статуса: Success либо Failed.

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

Как обычно это происходит в TeamCity — все нужно настраивать, и конфигурации сборки не являются исключением. Нажимаем на Edit Configuration в правом верхнем углу и видим список настроек:

Давайте подробнее остановимся на самых важных пунктах.

Скомпилировать проект

Поскольку у нас проект на ASP.NET в виде Solution’а из Visual Studio – тут тоже было всё просто.

Идём в меню «Build Steps» (Шаги сборки), выбираем runner type (а их тут действительно много) и останавливаемся на MSBuild. Почему именно на нём? Он даёт достаточно простой способ описать процесс сборки, даже достаточно сложный, добавляя или удаляя различные шаги в простом XML-файле.

Далее всё элементарно.

Build file path – путь к sln-файлу.MSBuild version, MSBuild ToolsVersion и Run platform выбираем под требования своего проекта.

Если в проекте несколько конфигураций, то можно использовать опцию Command line parameters для ввода примерно такого ключа:

где Production заменить на нужный конфиг.

Build Configurations

Каждая сборка, которая была выполнена по заданному сценарию, может иметь два статуса: Success либо Failed

Давайте подробнее остановимся на самых важных пунктах.

Подготовка сервера сборки

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

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

Ниже приведен список необходимых сведений.

Visual Studio для Mac — это включает xamarin. iOS и xamarin. Android.
Войдите в хранилище компонентов Xamarin — этот шаг является необязательным и необходим только в том случае, если приложение использует компоненты из хранилища компонентов Xamarin. Упреждающий вход в хранилище компонентов на этом этапе предотвратит любые проблемы, когда сборка TeamCity пытается скомпилировать приложение.
Xcode – Xcode требуется для компиляции и подписывания приложений iOS.
Xcode Command-Line Tools — это описано на шаге 1 раздела Установка обновления Ruby with rbenv .
Удостоверение подписывания Профили подготовки — импортируйте сертификаты и профиль подготовки через Xcode. Дополнительные сведения см. в статье Apple Guide об экспорте удостоверений подписывания и профилей подготовки .
Хранилища ключей Android — скопируйте необходимые хранилища ключей Android в каталог, к которому пользователь TeamCity имеет доступ, например .
Calabash — это необязательный шаг, если приложение содержит тесты, написанные с помощью Calabash. Дополнительные сведения см. в статье об установке Calabash в OS X Mavericks и в разделе Обновление Ruby with rbenv .

На следующей схеме показаны все эти компоненты.

После установки всех программ Войдите в учетную запись пользователя и убедитесь, что все программное обеспечение правильно установлено и работает. Это должно привести к компиляции решения и отправке приложения в тест App Center. Это можно упростить, запустив скрипт сборки, как описано в следующем разделе.

Артефакты

Открываем General Settings проекта и находим поле Artifact paths. Прописываем там следующее:

Далее нужно добавить шаг сборки, который будет прогонять lint. Настройки этого шага зависят от раннера.

Pipeline

Пример направленного ациклического графа

Composite Build

Еще одна классная фича в TC — композитная конфигурация сборки.

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

Создание такой конфигурации отличается от обычной лишь одной настройкой:

В поле Build configuration type необходимо выбрать Composite, а далее просто добавить снепшот-зависимости на наши новые конфигурации.

Далее добавляем две конфигурации в зависимости нашего композитного билда:

Добавляем Generate Build Number и Bishop-scan в зависимости и смотрим итоговый граф:

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

Build Agent

Перед тем как начать разбираться в TeamCity, стоит понять, как в нем построен процесс сборки и выполнения CI/CD задач.

В TeamCity есть такое понятие, как build agent — это какая-то машина, на которой происходит процесс сборки. Единовременно агент может выполнять всего одну сборку.

Сборка проходит в несколько шагов:

После некоторого события, которое было поймано триггером сборки (build trigger), сборка попадает в очередь и будет начата сразу, как только появится свободный агент.
Начинается сборка, которая поочередно выполняет все шаги сборки (build steps), которые были указаны в конфигурации (build configuration).
Сборка заканчивается, и ее результаты сохраняются в истории конфигурации.

Забрать свежие изменения из репозитория

Начинается всё с немудрёного создания проекта.

После – создание «build configuration» (конфигурации сборки). Конфигурация определяет сценарий сборки.

На втором же шаге создания конфигурации нас спросят об использованной VCS, так что отвечаем честно, что у нас тут git. У вас может быть другая VCS – не теряйтесь. Добавление нового репозитория производится кнопкой Create and attach new VCS root.

Итак, ключевые настройки:

VCS root ID можно не трогать – уникальный код, как ни крути. Если оставить пустым, генерируется автоматически;
Fetch URL – тот адрес, с которого мы будем забирать содержимое репозитория;
Default branch – ветка, с которой будет браться информация;
Authentication method – самое интересное – способ аутентификации. Тут может быть и доступ без авторизации (если данные лежат на внутреннем сервере, например), и по ключу, и по паролю. Для каждого варианта дополнительные поля будут свои, сами понимаете.

Остальное многообразие опций – на ваш вкус и цвет.

Далее, нужно настроить автоматический запуск задания. Идём в «Build Triggers» (условия сборки) и выбираем условие VCS Trigger – при настройках по умолчанию он будет раз в минуту проверять наличие новых коммитов в репозитории, а если таковые найдутся – запустит задание на выполнение.

VCS Roots

Здесь содержится набор настроек и правил, нужных для того, чтобы TeamCity мог подключиться к вашей системе контроля версий. При добавлении нового VCS Root он становится доступен внутри всех конфигураций, которые содержатся в проекте.

Для «соединения» TeamCity с системой контроля версий необходимо указать следующие параметры:

Type of VCS	Тип системы контроля версий (например, Subversion или Git)
VCS root name	Уникальное имя нового рута
VCS root ID	Уникальный ID рута, который затем может использоваться в REST API
Fetch/Push URL	URL до репозитория в формате https://, ssh://git@
Default branch	Основная ветка, изменения которой будет «отлавливать» TeamCity

Далее нужно указать способ авторизации. Это может быть пароль или приватный ключ. На наших агентах установлены ключи, поэтому выбран default private key.

Крайне рекомендую на каждый репозиторий заводить всего лишь один VCS Root.