Jetbrains teamcity что это

Обновлено: 05.07.2024

Быстрый запуск инструмента непрерывной интеграции TeamCity

Все слышали о знаменитой Intellij IDEA, ее производственная компания Jetbrains не только запустила ряд полезных IDE, но и запустила популярный язык Kotlin. У Jetbrains также есть очень полезный продукт - инструмент непрерывной интеграции, который я представлю сегодня.TeamCity。

установка

Установить под Windows

Конечно, вы можете видеть, что на странице загрузки есть несколько операционных систем, будь то Windows, macOS или Linux, вы можете запустить TeamCity.

Установить под Docker

Первое, что нужно сделать, - это вытащить изображение TeamCity.

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

Используйте TeamCity

инициализация

После завершения установки и запуска TeamCity мы можем получить к нему доступ на веб-странице. Если это система Windows, порт по умолчанию - 80, если это другая система, это порт, который вы установили сами. Затем зайдите в браузер localhost:80 Вы можете увидеть страницу TeamCity. Вам необходимо настроить и инициализировать пользователя для первого использования, а затем подождать некоторое время.

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

База данных конфигурации

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

Например, если я планирую использовать базу данных MySQL, мне нужно загрузить драйвер MySQL JDBC. mysql-connector-java-5.1.42-bin.jar , А затем поместите его в папку данных TeamCity lib\jdbc Затем настройте соответствующее имя пользователя и пароль базы данных в TeamCity для доступа к базе данных.

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

Новый проект

Когда вы используете TeamCity в первый раз, вам будет предложено создать новый проект. Если вы хотите создать новый проект позже, щелкните в правом верхнем углу Administration ОК. При создании нового проекта вам необходимо указать URL-адрес кода проекта и инструменты поддержки, такие как Git и SVN. Вот мой простой небольшой проект в качестве примера. Его код находится вВот。

Затем TeamCity проверит введенный адрес и напомнит нам подтвердить.

Таким образом создается проект.

Настройте этап сборки

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

Кроме того, отсюда мы видим важность строительных инструментов. Если проект является Java-проектом и для управления проектом использует хорошо известный в отрасли инструмент сборки, такой как Maven или Gradle, то TeamCity необходимо только автоматически определять все этапы настройки. Если вы не используете такой инструмент, возможно, вам придется настроить процесс сборки самостоятельно. (Например, моя настольная программа WPF может быть установлена только мной)

Затем вам нужно установить шаг сборки, просто выберите Visual Studio (sln).

Таким образом настраиваются этапы построения проекта.

Построить проект

После настройки шагов сборки вы можете начать сборку проекта на следующем шаге. Щелкните вверху страницы Projects Чтобы вернуться к просмотру проекта. Затем нажмите на правую сторону предмета Run ОК.

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

Тестовые задания

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

Сначала щелкните ссылку «Сборка» соответствующего проекта, затем щелкните «Параметры сборки» («Параметры») и найдите этапы сборки в нижней части страницы.

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

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

Автоматическая сборка

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

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

Уведомление по электронной почте

CI и CD корпоративного уровня за 0 $.

TeamCity
Professional

Нужна техподдержка корпоративного уровня? Рассмотрите возможности версии Enterprise.

Создавайте до 100 конфигураций сборки (задач) и выполняйте неограниченное количество сборок.

Выполняйте до 3 сборок одновременно. Добавляйте агенты по мере необходимости.

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

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

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

Ваш круглосуточный специалист по сборке

Мощные возможности непрерывной интеграции

Удаленный запуск и предварительное тестирование коммитов

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

Отображение хода выполнения сборки в реальном времени

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

Интеллектуальная конфигурация

Иерархия проектов

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

Шаблоны

Создавайте шаблоны с общими настройками и наследуйте от них любое количество конфигураций сборки.

Зависимости и цепочки сборки

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

Управление конфигурацией из кода

Создавайте свой конвейер CI и CD при помощи кода, используя конфигурационные скрипты на языке TeamCity — Kotlin DSL.

Создание проектов из URL-адреса

При создании проекта в TeamCity просто укажите на репозиторий с вашим файлом .teamcity/settings.kts. TeamCity автоматически создаст проект со всеми необходимыми настройками и конфигурациями сборки согласно их описанию в коде.

Переносимость

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

Настоящий язык программирования

Поскольку используемый TeamCity предметно-ориентированный язык (DSL) основан на Kotlin, вы можете повторно использовать код, создавать конфигурации динамически, а также пользоваться возможностями автодополнения и навигации по коду.

Легкий в освоении

Не уверены, с чего начать работу с DSL? Воспользуйтесь командой «View DSL» в пользовательском интерфейсе, чтобы увидеть образец описания настроек при помощи DSL.

Давайте обсудим эти два популярных инструмента непрерывной интеграции и их различия!

И Так. Начнем.

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

Термин CI/CD, обозначающий непрерывную интеграцию и непрерывную доставку, стал очень популярным. Это практика DevOps, которая помогает разрабатывать и доставлять приложение гораздо быстрее и надежнее. Это методология, которая автоматизирует все этапы, начиная от бизнес-требований и заканчивая развертыванием на производстве с помощью инструмента CICD. Это гораздо лучше и безопаснее, чем делать все вручную. Сейчас существует множество инструментов, доступных для CI/CD, поэтому выбор правильных инструментов может привести к путанице.

Почему Дженкинс?

Jenkins - самый популярный инструмент непрерывной интеграции с открытым исходным кодом. Это де-факто стандарт для решения непрерывной интеграции. Вы можете установить Jenkins на основные операционные системы, такие как Windows или Linux, так как он работает на Java. Первоначально он был создан как инструмент автоматизации сборки для Java-приложений. С тех пор он сильно эволюционировал и имеет более 1400 плагинов, которые легко интегрируются с другими платформами и инструментами.

Дженкинс-это основной инструмент для непрерывной интеграции и непрерывной доставки в процессе разработки программного обеспечения. Он прост в установке и предоставляет панель мониторинга для управления проектами, доступ к которой можно легко получить через браузер. Разработчики используют Jenkins для автоматической сборки, интеграции, тестирования и развертывания кода. Сначала разработчики проверяют свой код, затем Дженкинс берет измененный исходный код, запускает сборку и при необходимости запускает тест. Как только сборка завершится, вы получите выходные данные на панели мониторинга Jenkins, и уведомление может быть отправлено разработчику, если оно установлено.

Почему TeamCity?

TeamCity-это коммерческий сервер CI/CD, который также основан на java. Это инструмент автоматизации сборки и управления, созданный компанией JetBrains. Слоган TeamCity - “Мощная непрерывная интеграция из коробки“, и этот инструмент его оправдывает. Он предлагает почти все функции Дженкинса с несколькими дополнительными. TeamCity может интегрироваться с Docker для автоматического создания контейнеров через docker-compose. Он имеет поддержку интеграции с инструментом Jira для легкого отслеживания проблем.

Дженкинс против TeamCity

Open-Source против коммерческих

Самое основное отличие заключается в том, что Jenkins-это инструмент непрерывной интеграции с открытым исходным кодом, а TeamCity-коммерческий инструмент. Проект Jenkins выпущен под лицензией MIT и поддерживается разработчиками по всему миру. TeamCity разрабатывается и поддерживается материнской компанией JetBrains.

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

Эксклюзивные функции

Чтобы установить Jenkins в вашу систему, вам нужно иметь в ней Java. Настройка Дженкинса проста, когда оба они уже есть в системе. После завершения установки вы можете начать работать с Jenkins на его веб-интерфейсе. Установка TeamCity также очень проста. Вам нужно скачать сервер TeamCity, перейти к документации и следовать указанным инструкциям.

Безопасность

Хорошая часть коммерческой ценности TeamCity заключается в том, что JetBrains поддерживают ее так, чтобы она была зафиксирована в приоритете для любого обнаружения безопасности. TeamCity обеспечивает интеграцию с плагином Snyk security plugin, который может выполнять сканирование уязвимостей в конвейере сборки. Это поможет вам идентифицировать и устранить все риски и угрозы, которые существуют в ваших сборках. Учитывая, что Дженкинс является открытым исходным кодом, снижение риска может быть отложено, поскольку все зависит от сообщества разработчиков.

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

Дженкинс свободен в использовании, так как он является открытым исходным кодом, и именно поэтому он является предпочтительным выбором для многих организаций. Организации экономят приличную сумму, не тратя ничего на такой инструмент CI, как Дженкинс. TeamCity не является бесплатным для использования. Он поставляется с двумя лицензиями, которые являются лицензией профессионального сервера и лицензией корпоративного сервера. В профессиональной серверной лицензии вы можете использовать 100 конфигураций сборки и 3 агента сборки бесплатно, а после этого 299$ за 1 дополнительный агент сборки и 10 конфигураций сборки. Лицензия TeamCity enterprise Server начинается с 3 агентов, что обеспечивает неограниченное количество конфигураций сборки, начиная с 1,999$.

Теперь вы знаете разницу между двумя самыми популярными инструментами непрерывной интеграции – Jenkins и TeamCity. Когда вы выбираете инструмент CI для своей организации, вам нужно проверить несколько параметров, таких как параметры хостинга, доступные интеграции, повторно используемая библиотека кода, поддержка контейнеров и то, насколько легко использовать и изучать этот инструмент. Инструмент непрерывной интеграции, который передает эти параметры, был бы отличным вариантом.

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

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

Сегодня я не про IntelliJ IDEA, а про TeamCity. Сразу говорю, что до 20 конфигураций сборки и до 3 агентов это чудо бесплатно. Чего, в общем-то, для одного проекта среднего размера даже достаточно.

TeamCity — это инструмент Continuous Integration. Как и Jenkins (который форк Hudson). К сожалению, Jenkins — единственный открытый CI. Попробую рассказать, чем закрытый TeamCity может быть лучше.

Я несколько лет использовал Jenkins. А тут пару месяцев наслаждаюсь TeamCity.

Первое, чем хвастаются JetBrains — это поддержка различных систем сборки. Действительно, Jenkins нам предлагает или сборку Maven проекта, или написать скрипт (на Bash, Ruby, Python, чем угодно), который сделает все, что вам нужно.

TeamCity же предлагает солидный выбор сборщиков. От того же Maven и Ant, до прямой сборки проектов IntelliJ IDEA, Xcode или солюшенов Visual Studio. Интеграция со сборщиком означает не просто легкую его конфигурацию, но и «понимание» со стороны TeamCity хода сборки, что выражается в правильном учете времени сборки, и его прогнозировании, и потрясающей визуализации журнала сборки, с подсветкой ошибок и фолдингом.

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

TeamCity знает о вашем коде гораздо больше. Работа с VCS происходит независимо от сборок. TeamCity наблюдает за ветками, сразу за всеми ветками, за которыми нужно, в репозитории и ведет учет всех изменений. Можно посмотреть весьма приятные на вид диффы. Ну а если с данным репозиторием (и ветками) связан какой-то проект, то еще и видно, в какие билды вошли изменения. И наоборот: какие изменения вошли в билды.

Эта работа с репозиториями происходит на самом сервере TeamCity, агенты сборки тут не задействованы. Передача исходников на агент сборки может проходить двумя способами. Либо на агенте уже есть настроенная рабочая копия или клон репозитория, и TeamCity будет обновлять эту рабочую копию до нужной версии для сборки. Именно так и только так умеет работать Jenkins. А можно не заморачиваться настройкой VCS на агентах, TeamCity сервер закачает все исходники на агента самостоятельно. Иногда это может быть полезно.

В Jenkins, по крайней мере без сторонних плугинов, мы имеем дело с плоским списком проектов. И в лучшем случае мы можем создавать новые проекты на основе существующих. Или запускать сборку другого проекта в зависимости от сборки другого. Каждый проект — это длииинююющий список настроек: от настроек системы контроля версий до post-build action.

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

Сами конфигурации сборки могут быть созданы на основе шаблонов. Опять таки с полноценным наследованием. Можно описать сборку в общих чертах, с кучей параметров в тех местах, где что-то может меняться. А подставлять параметры можно вообще куда угодно, хоть в скрипты. А потом, на основе шаблона, создать уже конкретную конфигурацию сборки. И TeamCity проследит, чтобы все упомянутые параметры были определены. А если что-то нужно поменять в шаблоне, это повлияет на все созданные по шаблону сборки. Я же говорю, полноценное наследование.

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

TeamCity устроен посложнее. Cервер тут такое же веб-приложение на Java. Но есть и полноценные агенты в виде демонов/сервисов, которые нужно устанавливать и немножко настраивать. Иногда это усложняет жизнь в плане всяких файерволов и маршрутизации.

Строго говоря, TeamCity не делает ничего такого, чего не мог бы сделать Jenkins. Но в TeamCity проще настраивать сборки, проще создавать похожие сборки, нагляднее видеть, что происходит, им приятнее пользоваться. Сильно проще и сильно приятнее.

Как уже говорилось в статье Введение в непрерывную интеграцию , непрерывная интеграция (CI) является полезной практикой при разработке мобильных приложений. Существует множество вариантов для серверного программного обеспечения непрерывной интеграции. в этом руководством основное внимание уделяется TeamCity от JetBrains.

Существует несколько различных перестановок установки TeamCity. В следующем списке описаны некоторые из этих перестановок.

Windows служба — в этом сценарии TeamCity запускается, когда Windows загружается как служба Windows. Он должен быть связан с узлом сборки Mac для компиляции любых приложений iOS.

запустить управляющую программу в OS X — концептуально это похоже на работу в качестве Windows службы, описанной на предыдущем шаге. По умолчанию сборки будут выполняться с учетной записью root.

Учетная запись пользователя в OS X — можно запустить TeamCity под учетной записью пользователя, которая запускается каждый раз при входе пользователя в систему.

Из предыдущих сценариев запуск TeamCity под учетной записью пользователя в OS X является самым простым и простым в установке.

Существует несколько шагов, связанных с настройкой TeamCity:

Установка TeamCity — установка TeamCity не рассматривается в этом руководство. В этом учебнике предполагается, что TeamCity установлен и работает под учетной записью пользователя. Инструкции по установке TeamCity можно найти в документации по TeamCity 8 с помощью JetBrains.

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

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

Требования

Требуется опыт работы с тестом App Center .

Знание TeamCity 8,1 является обязательным. Установка TeamCity выходит за рамки данного документа. Предполагается, что TeamCity установлен в OS X Mavericks и выполняется под обычной учетной записью пользователя, а не с учетной записью root.

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

В этом руководства не рассматривается установка Xamarin без монитора.

Настройка брандмауэра

В некоторых ситуациях тест (или устройство, выполняющее тестирование) должно взаимодействовать с веб-серверами, защищенными брандмауэром. В этом сценарии брандмауэр должен быть настроен на разрешение трафика со следующих IP-адресов:

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

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

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

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

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

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

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

скрипт сборки может быть простым, как файл PowerShell (в Windows) или скрипт bash (в OS X). При создании скрипта сборки существует несколько вариантов для языков сценариев:

Rake — это язык Domain-Specific (DSL) для создания проектов на основе Ruby. Rake обладает преимуществом популярности и обширной экосистемой библиотек.

psake — это библиотека Windows PowerShell для создания программного обеспечения

Использование языка сценариев зависит от ваших предпочтений и требований.

можно использовать систему сборки на основе XML, например MSBuild или NAnt, но у них отсутствует выразительность и удобство поддержки DSL, предназначенное для создания программного обеспечения.

Параметризация скрипта сборки

Для процесса создания и тестирования программного обеспечения требуются сведения, которые должны храниться в секрете. Для создания APK может потребоваться пароль для хранилища ключей и (или) псевдонима ключа в хранилище ключей. Аналогично тесту App Center требуется ключ API , уникальный для разработчика. Эти типы значений не должны быть жестко запрограммированы в скрипте сборки. Вместо этого они должны передаваться в качестве переменных в скрипт сборки.

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

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

Существует два возможных варианта хранения этих конфиденциальных значений:

Файл конфигурации — для защиты ключа API это значение не должно быть возвращено в систему управления версиями. Файл может быть создан для каждого компьютера. Метод считывания значений из этого файла зависит от используемого языка сценариев.

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

Каждый из этих вариантов имеет свои преимущества и недостатки. TeamCity хорошо работает с переменными среды, поэтому в этом разделе мы советуем использовать этот метод при создании скриптов сборки.

Этапы сборки

Скрипт сборки должен выполнять следующие действия:

Скомпилируйте приложение — включает в себя подпись приложения с правильным профилем подготовки.

Отправьте приложение в Xamarin Test Cloud — это включает в себя подписывание и отправку ZIP-файла apk с соответствующим хранилищем ключей.

Эти два действия будут более подробно описаны ниже.

Компиляция приложения Xamarin. iOS

Следующая командная строка позволяет указать сборку выпуска решения SOLUTION_FILE. sln для iPhone. Расположение IPA можно задать, указав IpaPackageDir свойство в командной строке:

На компьютере Mac с помощью Xbuild:

Команда Xbuild обычно находится в каталоге /либрари/фрамеворкс/моно.фрамеворк/коммандс.

В Windows с помощью MSBuild:

MSBuild не будет автоматически развертывать $( ) выражения, переданные в командной строке. По этой причине рекомендуется использовать полный путь при задании в IpaPackageDir командной строке.

Дополнительные сведения о свойстве см. в заметках о выпуске iOS 9,8 IpaPackageDir .

Компиляция приложения Xamarin. Android

Чтобы скомпилировать приложение Android, используйте Xbuild (или MSBuild в Windows):

При компиляции приложения Android Xbuild использует проект, а приложение iOS Xbuild использует решение.

Отправка Xamarin. тестов пользовательского интерфейса в центр приложений

Тестов пользовательского интерфейса отправляются с помощью интерфейса командной строки центра приложений, как показано в следующем фрагменте кода:

При выполнении теста результаты теста будут возвращены в виде XML-файла стиля NUnit с именем report.xml. TeamCity будет отображать сведения в журнале сборки.

Отправка тестов Calabash в центр приложений

Тесты Calabash отправляются с помощью интерфейса командной строки центра приложений, как показано в следующем фрагменте кода:

Дополнительные сведения о отправке тестов Calabash см. в документации по Xamarin, посвященной отправке тестов Calabash в Test Cloud.

Создание Project TeamCity

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

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

под корневым Project создайте новый подпроект:

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

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

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

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

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

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

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

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

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

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

Сводка

В этом руководство описано, как использовать TeamCity для создания мобильных приложений Xamarin и их отправки в тест App Center. Мы обсуждали создание скрипта сборки для автоматизации процесса сборки. Скрипт сборки отвечает за компиляцию приложения, отправку в тест App Center и ожидание результатов.

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

Читайте также: