Публікуємо програми iOS в App Store з GitLab та fastlane

Як 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, але для реального застосування, напевно, краще підійде матч.

Підготовка 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 у проекті, запустіть 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("[email protected]") # 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. Якщо ви використовуєте матч або ще щось, внесіть зміни.

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.

Джерело: habr.com