18.03.2019 08:45
dinisoft 0 1900 Источник


Как GitLab с fastlane собирает, подписывает и публикует приложения для iOS в App Store.


Недавно у нас был пост о том, как быстро собрать и запустить приложение Android с GitLab и fastlane. Здесь мы увидим, как собрать и запустить приложение iOS и опубликовать его в TestFlight. Зацените, как круто я вношу изменение на iPad Pro с GitLab Web IDE, беру сборку и получаю обновление тестовой версии приложения на том же iPad Pro, где я его разработал.


Здесь мы возьмем простое приложение для iOS на Swift, с которым я записывал видео.


Пара слов о конфигурации Apple Store


Нам понадобится приложение в App Store, сертификаты распространения и профиль инициализации, чтобы связать все вместе.


Самое сложное тут — настроить права на подпись в App Store. Надеюсь, с этим вы разберетесь сами. Если вы новичок, я укажу нужное направление, но здесь мы не будем говорить о тонкостях управления сертификатами Apple, к тому же они постоянно меняются. Этот пост поможет приступить к делу.


Мои приложения


Нужно приложение в App Store Connect, чтобы у вас был ID для конфигурации .xcodebuild. Профиль и ID приложения объединяют сборки кода, цены и доступность, а еще конфигурацию TestFlight для распространения тестовых приложений среди пользователей. Не делайте общедоступное тестирование, хватит и приватного, если у вас маленькая группа, простая настройка и не нужны дополнительные разрешения от Apple.


Профиль инициализации


Кроме сетапа приложения вам нужны ключи распространения и разработки iOS, созданные в разделе Certificates, Identifiers & Profiles (Сертификаты, идентификаторы и профили) в консоли Apple Developer. Все эти сертификаты можно объединить в профиле инициализации.


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


Другие варианты


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


В этом примере я использую подход cert и sigh, но для реального применения, наверное, лучше подойдет match.


Подготовка GitLab и fastlane


Подготовка CI Runner


Собрав все эти данные, переходим к конфигурации GitLab-раннера на устройстве MacOS. К несчастью, делать приложения iOS реально только в MacOS. Но все может измениться, и если ждете подвижек в этой области, — следите за проектами, вроде xcbuild и isign, и нашей внутренней задачей gitlab-ce#57576.


Настроить раннер очень просто. Следуйте актуальным инструкциям по настройке GitLab Runner в macOS.


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


sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64
sudo chmod +x /usr/local/bin/gitlab-runner
cd ~
gitlab-runner install
gitlab-runner start

Связка ключей Apple должна быть настроена на этом хосте с доступом к ключам, которые нужны Xcode для сборки. Самый простой способ это протестировать — войти как пользователь, который запустит сборку, и попробовать выполнить сборку вручную. Если система запросит доступ к связке ключей, выберите «Всегда разрешать», чтобы CI работал. Возможно, стоит войти и понаблюдать за первой парой пайплайнов, — убедиться, что они больше не просят связки ключей. Беда в том, что Apple не упрощает нам работу с автоматическим режимом, но когда вы его наладите, все будет нормально.


fastlane init


Чтобы использовать fastlane в проекте, запустите fastlane init. Просто следуйте инструкциям по установке и запуску fastlane, особенно в разделе про Gemfile, ведь нам нужен быстрый и предсказуемый запуск через автоматический конвейер CI.


В каталоге проекта запустите эти команды:


xcode-select --install
sudo gem install fastlane -NV
# Alternatively using Homebrew
# brew cask install fastlane
fastlane init

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


1. fastlane/Appfile


Тут ничего сложного. Просто проверьте, что Apple ID и ID приложения указаны правильно.


app_identifier("com.vontrance.flappybird") # The bundle identifier of your app
apple_id("your-email@your-domain.com") # Your Apple email address

2. fastlane/Fastfile


Fastfile определяет шаги сборки. Мы используем много встроенных возможностей fastlane, так что здесь все тоже понятно. Создаем одну линию, которая получает сертификаты, выполняет сборку и загружает ее в TestFlight. Можете разделить этот процесс на разные задания, если нужно. Все эти операции (get_certificates, get_provisioning_profile, gym и upload_to_testflight) уже входят в fastlane.


Действия get_certificates и get_provisioning_profile связаны с подходом подписания cert и sigh. Если вы используете match или что-то еще, внесите изменения.


default_platform(:ios)

platform :ios do
  desc "Build the application"
  lane :flappybuild do
    get_certificates
    get_provisioning_profile
    gym
    upload_to_testflight
  end
end

3. fastlane/Gymfile


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


https://docs.fastlane.tools/actions/gym/

Наш .gitlab-ci.yml


Итак, у нас есть CI-раннер для проекта, и мы готовы испытать пайплайн. Посмотрим, что у нас в .gitlab-ci.yml:


stages:
  - build

variables:
  LC_ALL: "en_US.UTF-8"
  LANG: "en_US.UTF-8"
  GIT_STRATEGY: clone

build:
  stage: build
  script:
    - bundle install
    - bundle exec fastlane flappybuild
  artifacts:
    paths:
    - ./FlappyBird.ipa

Все отлично! Мы задаем формат UTF-8 для fastlane, как и требуется, используем стратегию clone с исполняющей программой shell, чтобы у нас было чистое рабочее пространство для каждой сборки, и просто вызываем flappybuild fastlane, как видно выше. В итоге мы получаем сборку, подпись и деплой последней сборки в TestFlight.


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


Другие переменные среды


Здесь есть пара переменных среды, на которых все работает.


FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD и FASTLANE_SESSION


Для аутентификации в App Store и загрузки в TestFlight нужна аутентификация для fastlane. Для этого создайте пароль для приложения, который будет использоваться в CI. Подробности здесь.


Если у вас двухфакторная аутентификация, создайте переменную FASTLANE_SESSION (инструкции там же).


FASTLANE_USER и FASTLANE_PASSWORD


Чтобы cert и sigh вызывали профиль иницализации и сертификаты по запросу, нужно задать переменные FASTLANE_USER и FASTLANE_PASSWORD. Подробности здесь. Это не нужно, если вы используете другой метод подписания.


В заключение


Посмотреть, как все это работает, можно в моем простом примере.


Надеюсь, это было полезно, и я вдохновил вас работать со сборками iOS в проекте GitLab. Вот еще советы по CI для fastlane, на всякий случай. Может, захотите использовать CI_BUILD_ID (для инкрементных сборок), чтобы автоматически инкрементировать версию.


Еще одна крутая возможность fastlane — автоматические скриншоты для App Store, которые очень просто настроить.


Расскажите в комментариях о своем опыте и поделитесь идеями по улучшению GitLab для разработки приложений iOS.

Комментарии (0)