Полное руководство по автоматическому развертыванию приложений iOS с помощью CI-CD

Создавайте, тестируйте и развертывайте свои приложения в AppStore Connect без использования Fastlane

Фон

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

В этой статье мы рассмотрим, как мы можем автоматически создавать, тестировать и развертывать наше приложение для iOS в AppStore без использования Fastlane. Сборка будет отправлена в Testflight после слияния PR в основной ветке репозитория git.

Чтобы упростить навигацию, я разделил статью на 3 отдельных раздела. Мы изучим сценарии, чтобы —

Автоматизировать сборку
Автоматизируйте тесты
Автоматизируйте развертывание

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

Например, я использовал GitLab CI, но вы можете взять команды сценария и легко встроить их в любой другой CI, такой как Jenkins и Github Actions.

Примечание . Я полагаю, что у всех вас есть общее представление о развертывании приложений в ITC (AppStore Connect), и вы уже создали свое приложение для консоли AppStore.

Базовая настройка

Чтобы запустить наш пайплайн на Gitlab CI, требуется некоторая базовая настройка. Вы можете обратиться к данной документации за руководством.

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

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

Начнем с автоматизации рабочего процесса сборки.

1. Автоматизируйте сборку

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

У нас будет 3 этапа: сборка, тестирование и развертывание. Все они будут работать линейно.

Начнем с добавления скрипта этапа build. Как вы, возможно, заметили в базовой настройке GitLab CI, нам нужно создать файл .gitlab-ci.yml, чтобы добавить наш скрипт сборки.

Скрипт содержит 2 основных раздела — stages и build_project. Мы уже обсуждали этапы, поэтому давайте сосредоточимся на последнем.

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

Раздел сценария содержит —

Установка модуля: если вы добавили внешние модули в свой проект, то сначала нам нужно будет установить их в CI. В случае отсутствия стручков пропустите это.
Команда сборки: после этого мы создаем наш проект на CI, используя инструмент командной строки xcodebuild, предоставленный Xcode. Он поставляется в комплекте с Xcode, поэтому установка не требуется.
Мы предоставили аргументы CODE_SIGNING_REQUIRED и CODE_SIGNING_ALLOWED для xcodebuild, а значение установлено на No, поскольку сборка не требует подписи.
Аргумент -scheme используется для указания схемы, которую мы хотим построить.
xcpretty --c pipe используется для чтения логов.

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

2. Автоматизируйте тесты

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

Мы будем использовать стадию test для запуска наших тестов. Вот скрипт, который нам нужно добавить в файл .gitlab-ci.yml для автоматизации.

Все почти так же, как и в сценарии build, но здесь мы передаем аргумент build в xcodebuild для запуска модульных и UI-тестов.

Кроме того, мы предоставили аргумент -sdk "iphonesimulator" -destination "platform=iOS Simulator,name=iPhone 11 Pro" для запуска тестов на устройстве iPhone 11 Pro. Это должно быть изменено в соответствии с потребностями.

3. Автоматизируйте развертывание

Теперь к заключительному этапу, и это развертывание.

Этот этап будет иметь больше настроек по сравнению с этапами test и build, так как нам нужно установить сертификат и профиль обеспечения в CI.

Мы рассмотрим установку сертификатов и профиля позже. Давайте сначала посмотрим, как выглядит наш скрипт.

Теперь это выглядит намного длиннее, чем скрипт сборки. Давайте посмотрим, что находится в разделе script шаг за шагом. Я разделил сценарий на 3 подраздела. Сначала мы изучим архив и этап экспорта.

а. Экспорт и архив

Первые две команды устанавливают сертификат и профиль предоставления из переменных CI. Пока не беспокойтесь о install_certificate.sh и install_profile.sh, мы поймем это в следующем разделе. Они используются только для управления сборками подписи.
Следующая команда — установка модуля, пропустите ее, если у вас нет модуля.
ARCHIVE_PATH используется для хранения пути к файлу, в котором мы хотим хранить файлы сборки.
Переменная EXPORT_PATH используется для хранения пути к каталогу, в котором мы хотим хранить экспортированный архив. Это будет отправлено в AppStore connect.
xcodebuild — clean archievecommand архивирует проект.
Аргумент -workspace принимает имя xcworkspace файла проекта.
Аргумент -sdk iphoneos используется для указания ОС, для которой мы хотим создать архив.
Аргумент -archivePath $ARCHIVE_PATH используется для указания пути к файлу, в котором мы хотим сохранить архив.
Аргумент PROVISIONING_PROFILE_SPECIFIER="${DIST_PROVISION_UUID}" используется для указания профиля обеспечения. Здесь мы использовали переменную среды, которую вскоре рассмотрим в следующем разделе.
CODE_SIGN_STYLE=Manual указывает, что мы хотим обрабатывать подпись вручную.
Аргумент CODE_SIGN_IDENTITY="${DIST_CODE_SIGN_IDENTITY}" используется для указания идентификатора подписи. Вскоре мы рассмотрим эту переменную env.
xcodebuild -exportArchive экспортирует архив как .ipa файл.
-archivePath $ARCHIVE_PATH используется для указания пути к сохраненному архиву.
Аргумент -exportOptionsPlist ExportOptionsAppStore.plist используется для указания нескольких конфигураций, связанных с экспортом. Мы рассмотрим его в следующем разделе.
Аргумент -exportPath $EXPORT_PATH используется для указания пути, по которому мы хотим сохранить файл .ipa.

Вот и все. Длинный список шагов, но довольно простой. К настоящему времени у нас будет файл .ipa, который мы можем отправить в AppStore для подключения.

Теперь давайте разберемся с конфигурацией подписи, которая используется в шагах archive и export.

б. Обработка подписи

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

Теперь вам нужно экспортировать сертификат в виде файла .p12, следуйте этому руководству для получения более подробной информации. Примечание. Запомните пароль, который вы ввели при экспорте сертификата.

Чтобы передать наши сертификаты в CI, мы будем использовать переменные среды Gitlab CI Environment, поскольку сертификаты должны храниться внутри репозитория git. Поскольку переменные среды являются строковыми значениями, нам нужно будет преобразовать сертификат и профиль в строку base64 с помощью этой команды.

base64 -i FILE_PATH -o outputfilename

Теперь давайте добавим их как переменные среды.

Перейдите в Project Setting =› CI-CD =› Variables и добавьте следующие переменные.

APPLE_DISTRIBUTION_CERTIFICATE_KEY= Значение Base64 файла сертификата распространения.
APPLE_DISTRIBUTION_CERTIFICATE_PASSWORD = Пароль сертификата, установленный во время экспорта.
BUILD_KEY_CHAIN = login.keychain(имя вашей связки ключей по умолчанию). Здесь будет установлен сертификат.
BUILD_KEY_CHAIN_PASSWORD = Добавьте пароль доступа к связке ключей
DISTRIBUTION_PROVISION_KEY = значение Base64 файла профиля обеспечения распространения.
DISTRIBUTION_PROVISION_UUID = Получить UUID из профиля обеспечения.
CODE_SIGN_IDENTITY = Получить из профиля обеспечения - раздел СЕРТИФИКАТЫ => Имя.

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

Вот сценарий install_certificate.sh, который используется для установки сертификата распространения.

Вот скрипт install_profile.sh, который используется для установки профиля обеспечения.

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

Кроме того, нам нужен еще один файл .plist, который использовался при экспорте сборки. Вот этот plist-файл .exportOptionsAppStore.

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

Мы закончили с архивированием, экспортом и подписанием. Теперь давайте разберемся, как мы можем отправить его в AppStore connect.

в. Подключить IPA к AppStore

Вот команда, которую мы использовали в сценарии развертывания для отправки IPA.

- xcrun altool --upload-app -t ios -f $IPA -u $ITC_USER_NAME -p $ITC_USER_PASSWORD

Здесь используется xcrun atool вместе с аргументом --upload-app. Аргумент -f — это путь к файлу, в котором мы предоставляем переменную $IPA, которую мы создали ранее.

Аргументы -u и -p используются для аутентификации для подключения к AppStore, и нам нужно передать адрес электронной почты Appstore и пароль для конкретного приложения. Вы можете обратиться к этому руководству для создания пароля для конкретного приложения.

Получив пароль, установите следующие переменные среды GitLab CI.

ITC_USER_NAME = Ваш адрес электронной почты в магазине приложений
ITC_USER_PASSWORD = Пароль для приложения

Вот и все для конфигурации atool.

Еще одна вещь: мы также сохраняемdSYMs сгенерированные во время архивирования как артефакты, чтобы убедиться, что они доступны, если они нам когда-нибудь понадобятся.

Мы собираемся запускать это задание только тогда, когда мы объединяем конкретную ветку с основной веткой, поэтому мы ограничиваем нашу работу, чтобы она не запускалась для других заданий, кроме основной (имя нашей главной ветки).

Тадда… Вот и все!!!

Вы получите последнее обновление приложения в Testflight после успешного завершения задания развертывания.

Заключить

Надеюсь, у вас будет общее представление обо всем процессе CI-CD. По сути, мы делаем все процессы автоматическими, чтобы мы могли получать нашу сборку Testflight всякий раз, когда в основной ветке есть какое-либо обновление.

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

Спасибо за вашу поддержку!

Если вам нравится то, что вы читаете, обязательно 👏 👏👏 это ниже — как писатель это означает мир!

Подпишитесь на Canopasилисвяжитесь с нами в Twitter, чтобы получать новости об интересных статьях!