Отправляем iOS сборки в Firebase и TestFlight с помощью Fastlane

Shot by Sơn Bờm

Автоматизация одна из самых важных частей современной разработки. Сегодня я хотел бы автоматизировать наш процесс сборки и распространения. Это, конечно, может быть сделано с помощью инструмента CI/CD, такого как Jenkins, тем не менее, все, что можно сделать на сервере, также может быть сделано локально. Fastlane - это набор инструментов, которые автоматизируют ваши сборки и предоставляют некоторые инструменты CLI для загрузки ваших сборок в такие пространства, как Firebase или App Store.

Fastlane состоит из набора инструментов, которые помогут нам различными способами. В сочетании с инструментом CI/CD вы получаете полный пакет автоматизации для вашего проекта iOS (Fastlane также поддерживает Android).

Эта статья может быть длинной, но в конце вы сможете

  • Запустить тесты для вашего проекта
  • Настроить автоматическое управление своими сертификатами и профилями подготовки
  • Создавать, загружать версию для разработчиков вашего проекта на Firebase и уведомляйте своих тестировщиков
  • Отправлять новые сборки в TestFlight

Первое, что вам нужно, это установить Fastlane. Инструкция здесь.

Теперь давайте настроим Fastlane для нашего проекта. Откройте терминал, перейдите в папку проекта и выполните команду

fastlane init

Fastlane спросит, для чего вы будете его использовать, введите 4 и нажмите Enter. Будем настраивать Fastlane самостоятельно:

[15:39:19]: What would you like to use fastlane for? 1. 📸 Automate screenshots 2. 👩‍✈️ Automate beta distribution to TestFlight 3. 🚀 Automate App Store distribution 4. 🛠 Manual setup - manually setup your project to automate your tasks ? 4

Теперь вы должны увидеть новую папку с названием fastlane. В этой папке есть два файла: Fastfile и Appfile. Мы их скоро отредактируем, но сначала давайте поймем, что это за файлы.

Fastfile – это файл, в котором мы собираемся написать наши lanes. Lanes - это функции, такие как запуск тестов, сборки или загрузки.

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

Прежде всего настроим наше модульное тестирование. Для этого мы будем использовать fastlane scan. Scan - это просто обертка для инструмента run_tests, имеющая несколько внутренних функций. Вернемся в терминал и введем fastlane scan init. Будет создан новый файл Scanfile. Здесь будет находиться наша тестовая конфигурация. Теперь замените его содержимое следующим:

skip_build(true) scheme("Debug-Development") # Or whatever your debug scheme is output_types("html") # The output of our tests will be in html devices(["iPhone 12"]) # You can add as many as you like here

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

+--------------------+---+ | Test Results | +--------------------+---+ | Number of tests | 2 | | Number of failures | 0 | +--------------------+---+

Сканирование также выведет отчет в HTML (JSon или JUnit). Обратите внимание, что есть новая папка, созданная сканированием, где содержимое вашего отчета о сканировании красиво представлено в формате HTML, как показано ниже.

Итак, теперь, когда мы закончили настройку Fastlane для тестирования – мы напишем lane для создания сборки нашего приложения и выгрузки его в Firebase App Distribution (ранее Fabric Beta). Я использовал слово lane для действия сканирования, которое мы использовали, хотя мы еще не написали lane. Сейчас это исправим.

Скоро будем билдить

Мы почти закончили… Чтобы сбилдить и загрузить ваше приложение, вы должны сначала создать сертификаты, профили и т.д. Что ж, эту трудоемкую задачу можно избежать, если вы решите использовать fastlane match.

Мы собираемся использовать репозиторий git (приватный или публичный, на самом деле не имеет значения) для хранения нашего сертификата и наших provisioning profiles, а match будет выполнять все управление и синхронизировать их. Если у вас есть какие-либо опасения по поводу хранения ваших .p12 и provisioning profiles в общедоступном репозитории, прочтите это. Существует начальная настройка, которая займет 5-10 минут, но после этого вы можете перестать беспокоиться об управлении сертификатами.

Мы будем использовать git для хранения наших сертификатов, поэтому нам нужен свежий репозиторий. Перейдите в любимую систему контроля версий (GitHub, Bitbucket и т.д.) и создайте новый репозиторий.

Вернитесь к своей консоли снова и введите

fastlane match init

Вам будет предложено выбрать в качестве поставщика хранилища git или google_cloud (выберите 1 - git), а в следующем запросе вставьте ссылку на только что созданный репозиторий.

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

fastlane match adhoc

На данный момент мы закончили с match

Теперь можем билдить? Ещё нет...

Перед сборкой нам нужно добавить плагин Firebase App Distribution. В вашем терминале внутри папки проекта введите

fastlane add_plugin firebase_app_distribution

Это установит плагин firebase, создаст Pluginfile с инструкциями по установке плагина firebase_app_distribution, а также будет ссылаться на файл плагина из вашего Gemfile. Поэтому, когда вы будете устанавливать пакет на другой компьютер, плагин также будет установлен. Теперь установите firebase cli, набрав

curl -sL https://firebase.tools | bash

Теперь запустите firebase login, и вы готовы к работе.

Примечание: вы не сможете использовать Firebase, пока не войдете в систему.

Примечание 2: я предполагаю, что у вас уже есть приложение в Firebase (пропускаю ту часть, где вам нужно открыть консоль Firebase, создать новый проект и добавить в него новое приложение).

Настало время сделать билд

Откройте свой Fastfile и добавим следующее:

desc "Builds Release-Development & uploads to Firebase App Distribution" lane :app_distribution do match( type: 'adhoc', app_identifier: [ 'com.max.MyAwesomeApp.dev', 'com.max.MyAwesomeApp.dev.widget' ] ) gym( project: 'MyAwesomeApp.xcodeproj', scheme: 'Release-Development', configuration: 'Release-Development', clean: true, output_directory: 'archives', output_name: 'MyAwesomeApp.development.ipa', export_method: 'ad-hoc' ) firebase_app_distribution( app: 'your_app_id', testers: ['list','of','testers','to', 'invite'], release_notes: 'some release notes', firebase_cli_path: '/usr/local/bin/firebase', ipa_path: 'archives/MyAwesomeApp.development.ipa' ) end

Давайте немного разберемся в этом. Сначала мы используем match

match( type: 'adhoc', app_identifier: [ 'com.max.MyAwesomeApp.dev', 'com.max.MyAwesomeApp.dev.widget' ] )

Если мы перейдем на другую машину, fastlane match будет управлять и устанавливать сертификаты, необходимые для нашего проекта. Все, что нам нужно сделать, это предоставить данные нашей учетной записи разработчика. Далее идет gym, который является псевдонимом build_app.

gym( project: 'MyAwesomeApp.xcodeproj', scheme: 'Release-Development', configuration: 'Release-Development', clean: true, output_directory: 'archives', output_name: 'MyAwesomeApp.development.ipa', export_method: 'ad-hoc' )

gym создает наш проект и сохраняет наши файлы .ipa и .dsym в каталоге архивов (output_directory), который будет создан в каталоге верхнего уровня нашего проекта. Именем нашего ipa будет имя output_name, указанное выше.

firebase_app_distribution( app: 'your_app_id', testers: ['list','of','testers','to', 'invite'], release_notes: 'some release notes', firebase_cli_path: '/usr/local/bin/firebase', ipa_path: 'archives/MyAwesomeApp.development.ipa' )

Наконец, нам нужно загрузить нашу сборку и отправить ее тестировщикам, клиентам или друзьям. Этим занимается функция firebase_app_distribution. Вы можете найти свой идентификатор приложения в консоли Firebase на вкладке «Приложения» вашего проекта. Имейте в виду, что каждое приложение (идентификатор Apple) имеет собственный идентификатор приложения. ipa_path - это путь к выходным данным, созданным gym во время нашей сборки.

Нажимаем и ждем.

app_distribution

Если все пойдет по плану, ваши тестировщики получат электронное письмо и смогут установить ваше приложение.

Flight в TestFlight

Также с помощью Fastlane мы можем загружать сборки в TestFlight.

Во-первых, мы будем использовать match для создания наших продакш профилей. Итак, открываем свой терминал, переходим в папку с проектом и введите

fastlane match appstore

и следуем инструкциям. Эта команда создаст ваши production сертификаты, если это необходимо, профили обеспечения установят их в вашу связку ключей, а также добавят их в репозиторий git (или облачное хранилище Google), которое вы указали во время инициализации соответствия выше.

Хорошо, теперь, когда мы получили производственные сертификаты, откройте ваш fastfile и добавьте в него новый lane

desc "Builds Release-Production & uploads to App Store Connect" lane :app_store do match( type: 'appstore', app_identifier: [ 'com.max.MyAwesomeApp', 'com.max.MyAwesomeApp.widget' ] ) scan(fail_build=true) gym( project: 'MyAwesomeApp.xcodeproj', scheme: 'Release-Production', configuration: 'Release-Production', clean: true, output_directory: 'archives', output_name: 'MyAwesomeApp.ipa', export_method: 'app-store' ) pilot( username: "apple id mail", team_id: "app store connect team id", app_identifier: 'com.max.MyAwesomeApp', app_platform: 'ios', ipa: "archives/MyAwesomeApp.ipa", skip_waiting_for_build_processing: true ) end

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

Затем мы запускаем сканирование с дополнительным аргументом. Этот аргумент останавливает сборку, если тесты не прошли.

gym - это то место, где мы создаем наше приложение. Мы используем нашу конфигурацию Release-Production для этой сборки.

Далее идет pilot. Pilot - это псевдоним действия upload_to_testflight. Pilot загрузит двоичный файл, созданный gym, в AppStore. Я предпочитаю не ждать обработки, поскольку иногда это может занять некоторое время, и я вручную выпускаю приложение для тестировщиков.

Что ж, это конец моего путешествия по скоростной полосе iOS. Надеюсь, вам все понравилось.

Спасибо за время! Надеюсь, эта статья окажется для вас полезной.

0
Комментарии
-3 комментариев
Раскрывать всегда