Использование TeamCity с Xamarin

2023-07-13

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

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

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

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

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

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

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

Требования

Требуется опыт работы с тестом Центра приложений.

Требуется знакомство с TeamCity 8.1. Установка TeamCity выходит за рамки область этого документа. Предполагается, что TeamCity устанавливается в ОС X Mavericks и выполняется под обычной учетной записью пользователя, а не корневой учетной записью.

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

Внимание

Это руководство не охватывает установку Xamarin без головы.

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

Чтобы тесты были отправлены в Xamarin Test Cloud, компьютер, отправляющий тесты, должен иметь возможность взаимодействовать с серверами Test Cloud. Брандмауэры должны быть настроены для разрешения сетевого трафика на серверы, расположенные в testcloud.xamarin.com на портах 80 и 443. Эта конечная точка управляется DNS, и IP-адрес подлежит изменению.

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

195.249.159.238
195.249.159.239

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

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

Visual Studio для Mac — включает в себя Xamarin.iOS и Xamarin.Android.
Войдите в хранилище компонентов Xamarin. Этот шаг является необязательным и требуется только в том случае, если приложение использует компоненты из хранилища компонентов Xamarin. Упреждающее вход в хранилище компонентов на этом этапе предотвратит любые проблемы при попытке сборки TeamCity скомпилировать приложение.
Xcode — Xcode требуется для компиляции и подписывания приложений iOS.
Средства командной строки Xcode. Это описано на шаге 1 раздела "Установка" руководства по обновлению Ruby с помощью rbenv .
Подписывание удостоверений и профилей подготовки — импорт сертификатов и профилей подготовки с помощью XCode. Дополнительные сведения см. в руководстве Apple по экспорту удостоверений подписывания и профилей подготовки.
Хранилища ключей Android — скопируйте необходимые хранилища ключей Android в каталог, к к который имеет доступ пользователь TeamCity, т. е. ~/Documents/keystores/MyAndroidApp1
Калабаш — это необязательный шаг, если приложение имеет тесты, написанные с помощью Calabash. Дополнительные сведения см. в руководстве по установке Calabash на OS X Mavericks и обновлении Ruby с помощью rbenv .

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

This diagram illustrates all of these components

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

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

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

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

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

Rake — это язык для конкретного домена (DSL) для создания проектов на основе Ruby. Rake имеет преимущество популярности и богатой экосистемы библиотек.
psake — это библиотека Windows PowerShell для создания программного обеспечения
FAKE — это DSL на основе F#, что позволяет использовать существующие библиотеки .NET при необходимости.

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

Примечание.

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

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

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

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

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

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

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

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

Действия по сборке

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

Скомпилируйте приложение. Это включает подписывание приложения с правильным профилем подготовки.
Отправьте приложение в Xamarin Test Cloud . Это включает подписывание и zip-файл, выравнивание APK с соответствующим хранилищем ключей.

Эти два шага подробно описаны ниже.

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

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

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

xbuild /p:Configuration="Release" \ 
       /p:Platform="iPhone" \ 
       /p:IpaPackageDir="$HOME/Builds" \
       /t:Build MyProject.sln

Команда xbuild обычно находится в каталоге /Library/Frameworks/Mono.framework/Commands.

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

msbuild /p:Configuration="Release" 
        /p:Platform="iPhone" 
        /p:IpaPackageDir="%USERPROFILE%\Builds" 
        /p:ServerAddress="192.168.1.3" /p:ServerUser="macuser"  
        /t:Build MyProject.sln

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

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

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

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

/Library/Frameworks/Mono.framework/Commands/xbuild /t:SignAndroidPackage /p:Configuration=Release /path/to/android.csproj

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

Отправка Xamarin.UITests в Центр приложений

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

appcenter test run uitest --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK-or-appname.IPA> --merge-nunit-xml report.xml --build-dir pathToUITestBuildDir

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

Дополнительные сведения о отправке UITests в Центр приложений см. в статье "Подготовка приложений Xamarin.Android" или "Подготовка приложений Xamarin.iOS".

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

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

appcenter test run calabash --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK-or-appname.IPA> --project-dir pathToProjectDir

Чтобы отправить приложение Android в app Center Test, необходимо сначала перестроить тестовый сервер APK с помощью calabash-android:

$ calabash-android build </path/to/signed/APK>
$ appcenter test run calabash --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK> --project-dir pathToProjectDir

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

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

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

Начните с входа в TeamCity через веб-браузер. Перейдите к корневому проекту:

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

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

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

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

Итоги

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

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