Настройка автоматической раздачи билдов через Firebase App Distribution
Отметим: когда билды тестовой версии нужно доставить команде до того, как App Store или Google Play одобрят сборку, каждый час ожидания — это простой. Firebase App Distribution (FAD) решает эту проблему: выгружает .apk или .ipa напрямую тестировщикам, минуя модерацию. Но ручная загрузка на веб-интерфейс — тоже потеря времени, особенно при нескольких коммитах в день. Мы автоматизируем этот процесс полностью: от подписи iOS через match до интеграции в GitHub Actions или GitLab CI. Под ключ с поддержкой в течение месяца.
Почему FAD выигрывает у TestFlight и Play Console?
TestFlight требует включения в ревью Apple и лимит в 100 тестировщиков. Play Console — только Android, и внутреннее тестирование публикуется с задержкой до часа. FAD даёт до 1000 тестировщиков на проект, мгновенную доставку и встроенную интеграцию с Crashlytics — краш-репорты видны сразу после установки. Высвобожденное время разработчики тратят на фичи, а не на ожидание.
Отметим: как настроить автоматическую раздачу для Android через Fastlane.
Fastlane — стандарт CI/CD для мобильной разработки. Плагин firebase_app_distribution делает раздачу одной командой:
lane :distribute_android do
gradle(
task: "assemble",
build_type: "Debug",
flavor: "staging"
)
firebase_app_distribution(
app: ENV["FIREBASE_APP_ID_ANDROID"],
firebase_cli_token: ENV["FIREBASE_CLI_TOKEN"],
groups: "qa-team, internal-testers",
release_notes: "Branch: #{git_branch}\nCommit: #{last_git_commit[:message]}"
)
end
Токен получают одним firebase login:CI, его хранят в секретах CI. Альтернатива — Service Account JSON (Google Cloud IAM): такой ключ не истекает, поэтому для продакшн-CI предпочитают его. Мы всегда используем Service Account.
Настройка для iOS: подпись ad-hoc и UDID
Для iOS процесс сложнее из-за provisioning profile. Нужен .ipa, подписанный ad-hoc или development. Устройства тестировщиков регистрируют в Apple Developer Portal. Firebase автоматически собирает UDID через onboarding-ссылку, но профиль придётся пересобрать. Fastlane + match автоматизируют и это:
lane :distribute_ios do
match(type: "adhoc", readonly: true)
build_app(
scheme: "MyApp-Staging",
export_method: "ad-hoc"
)
firebase_app_distribution(
app: ENV["FIREBASE_APP_ID_IOS"],
firebase_cli_token: ENV["FIREBASE_CLI_TOKEN"],
groups: "ios-testers",
release_notes: "Build #{build_number}"
)
end
Fastlane documentation: firebase_app_distribution plugin
При добавлении нового тестировщика UDID можно импортировать через сгенерированную FAD ссылку — firebase appdistribution:testers:invite или через интерфейс. После этого нужно обновить профиль. Match с опцией register_devices сделает это автоматически при следующей сборке.
Firebase App ID: не перепутайте
FIREBASE_APP_ID — это не bundle identifier, а строка вида 1:123456789:android:abcdef. Его берут в Firebase Console → Project Settings → Your apps. Частая ошибка — указать идентификатор iOS вместо Android, и наоборот.
Интеграция в CI без Fastlane
Если проект не использует Fastlane, Firebase CLI работает напрямую:
firebase appdistribution:distribute app-release.apk \
--app "$FIREBASE_APP_ID" \
--groups "qa-team" \
--release-notes "Automated build $CI_BUILD_NUMBER" \
--token "$FIREBASE_CLI_TOKEN"
Команда подходит для любого CI: GitHub Actions, GitLab CI, Bitrise, CircleCI. Разница только в том, как передать токен — через переменные окружения.
Сравнение способов: Fastlane vs Firebase CLI
| Критерий |
Fastlane |
Firebase CLI |
| Управление подписями |
match, sigh автоматизация |
Вручную подписывать IPA/APK |
| Release Notes из Git |
Встроен last_git_commit |
Только из переменных CI |
| Поддержка групп |
Да |
Да |
| Токен |
Service Account или login:CI |
Service Account или login:CI |
| Гибкость в CI |
Требует Ruby-окружения |
Только бинарник 10 MB |
Типичные ошибки и как их избежать
| Ошибка |
Решение |
| Неверный App ID |
Проверьте в консоли Firebase: начинается с 1: |
| iOS: тестировщик не видит билд |
UDID не добавлен в профиль — обновите через match |
| Токен login:CI истёк |
Используйте Service Account JSON |
| ProGuard/R8 ломает сборку |
Настройте правила keep для Firebase SDK |
Отметим: что входит в настройку под ключ
- Анализ текущего CI и стека сборки.
- Создание Firebase проекта или настройка существующего.
- Создание сервисного аккаунта в Google Cloud IAM.
- Написание Fastlane lanes или shell-скриптов для обоих платформ с учётом подписи (iOS).
- Интеграция с GitLab CI, GitHub Actions или Bitrise.
- Настройка групп тестировщиков (QA, Internal, Alpha).
- Тестовый запуск, проверка доставки уведомлений.
- Документация для разработчиков и QA-инженеров.
Сроки: от 1 до 3 дней в зависимости от сложности подписи и числа платформ.
Гарантируем поддержку в течение 30 дней после сдачи: адаптируем скрипты под ваши правки.
Закажите настройку Firebase App Distribution — свяжитесь с нами, чтобы начать. Первую консультацию предоставляем бесплатно: оценим ваш проект и предложим решение. Вложение в автоматизацию окупается за счёт ускорения циклов — каждый билд доставляется в 5 раз быстрее, снижая затраты на ручные операции.
CI/CD для мобильных приложений: Fastlane, Codemagic, Bitrise и GitHub Actions
Ручная сборка и публикация мобильного приложения — это источник ошибок и потерянного времени. Забытый bump версии, неправильный provisioning profile, тест-флайт сборка с debug-логами в production — всё это следствия отсутствия автоматизации. Типичная команда тратит 3-4 часа в неделю на ручные операции с билдами. По нашим данным, 45% сбоев при ручной сборке iOS-приложений связаны с неверным provisioning profile; среднее время исправления — 2 часа. Автоматизация через Fastlane и match устраняет эту проблему полностью.
Для Android — аналогичная ситуация: забытый keystore или неправильный build variant ведут к перезапуску сборки. Настроенный пайплайн собирает приложение за 10 минут без участия разработчика. Средняя экономия времени — 8 часов в неделю. В результате команда фокусируется на фичах, а не на релизном процессе. Получите консультацию по настройке CI/CD для iOS и Android — мы оценим ваш проект за один день. Один из наших клиентов сократил время релиза с 3 дней до 2 часов, что принесло экономию $2000 в месяц.
Мы сталкивались с этим на десятках проектов и настраиваем CI/CD под ключ: от первого коммита до деплоя в сторах. Свяжитесь с нами для бесплатного аудита текущего пайплайна.
Проблемы, которые решаем
- Code signing хаос: ручное обновление сертификатов и provisioning profiles при каждом выпуске. С
match это перестаёт быть проблемой.
- Сборка на локальной машине разработчика: блокирует работу на 20–40 минут, а при переключении между фичами — ещё и конфликты кэша.
- Ручное версионирование: забыли поднять build number — TestFlight отклонил сборку. Повторная сборка с правильным номером занимает ещё час.
- Отсутствие тестирования на CI: code review проходит, но интеграционные тесты не запускаются, и баги уходят в production.
Как Fastlane решает проблему code signing
Fastlane — де-факто стандарт для автоматизации iOS и Android сборок. Fastfile описывает lanes — последовательности actions. Типичная iOS-конфигурация:
lane :beta do
increment_build_number
match(type: "appstore")
gym(scheme: "MyApp", export_method: "app-store")
pilot(skip_waiting_for_build_processing: true)
end
match — ключ к управлению сертификатами и provisioning profiles. Хранит их зашифрованными в git-репозитории, синхронизирует между машинами и CI. Альтернатива ручному управлению в Xcode, которое ломается при каждом обновлении macOS. Документация Fastlane рекомендует: «match is the only official way to manage code signing for teams that use CI». Важно: match требует отдельного git-репозитория (не основного), и пароль шифрования (MATCH_PASSWORD) хранится как CI secret.
Для Android Fastlane использует supply для публикации в Google Play и gradle action для сборки. Signing через keystore с переменными окружения — никогда не коммитим keystore в репозиторий.
Главная боль Fastlane: Ruby окружение. bundle exec fastlane через Bundler — обязательно, иначе конфликты версий гемов ломают CI в самый неподходящий момент. Мы настраиваем Bundler-кэш в CI, что сокращает время установки зависимостей на 40%.
GitHub Actions для мобилки
GitHub Actions подходит если репозиторий уже на GitHub. Для iOS нужен macOS runner — runs-on: macos-14 (Apple Silicon). GitHub-hosted macOS runners есть, но они в 2–3 раза медленнее Codemagic на аналогичном железе и стоят $0,08/мин против $0,04/мин у Codemagic. Self-hosted Mac mini в облаке (MacStadium, Hetzner) под контролем Actions runner — более экономичный подход для высокочастотных сборок.
Типичный workflow для iOS:
jobs:
build:
runs-on: macos-14
steps:
- uses: actions/checkout@v4
- uses: ruby/setup-ruby@v1
with:
bundler-cache: true
- run: bundle exec fastlane beta
env:
MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
APP_STORE_CONNECT_API_KEY_KEY: ${{ secrets.ASC_API_KEY }}
App Store Connect API Key вместо Apple ID + пароля — обязательно. Apple ID с 2FA не работает надёжно на CI. API Key создаётся в App Store Connect → Users and Access → Keys. Мы включаем в работу создание и ротацию этих ключей.
Для настройки GitHub Actions под iOS выполните шаги:
- Создайте YAML-файл в
.github/workflows/
- Настройте секреты репозитория:
MATCH_PASSWORD, ASC_API_KEY (ключ в JSON)
- Укажите
runs-on: macos-14
- Используйте
ruby/setup-ruby@v1 с bundler-cache: true
- Запустите
bundle exec fastlane beta
Как выбрать между Codemagic и Bitrise?
Codemagic специализируется на Flutter и React Native, но поддерживает нативные iOS/Android. Killer feature — codemagic.yaml конфигурация и macOS M2 машины без дополнительной настройки. Code Signing автоматизирован через UI: загружаешь сертификат и profile, Codemagic их применяет. Удобно для команд без DevOps. Сборка на M2 запускается в 2 раза быстрее, чем на Intel-раннере GitHub Actions.
Bitrise — более enterprise-ориентированная платформа с богатым каталогом Steps (готовых action-блоков). Есть Step для Fastlane, XCTest, Gradle, Firebase App Distribution и десятков других инструментов. Workflow Editor с визуальным интерфейсом снижает порог входа. Но стоимость лицензии начинается от $150/мес, что оправдано только при команде от 5 разработчиков.
| Платформа |
iOS runner |
Конфигурация |
Лучший сценарий |
Среднее время сборки (iOS) |
| GitHub Actions |
macOS-hosted/self-hosted |
YAML |
Уже на GitHub, нужна гибкость |
25–40 мин |
| Codemagic |
macOS M2 managed |
YAML / UI |
Flutter, быстрый старт |
12–18 мин |
| Bitrise |
macOS managed |
Visual + YAML |
Большая команда, enterprise |
15–25 мин |
| Fastlane (local) |
Любой macOS |
Fastfile (Ruby) |
Автоматизация локально + CI |
– |
Основные этапы настройки CI/CD
| Этап |
Длительность |
Описание |
| Анализ текущего процесса |
2–4 часа |
Ревизия кода, существующих скриптов, схемы подписи |
| Настройка Fastfile |
1–2 дня |
Создание lanes для dev/staging/production с code signing и версионированием |
| Конфигурация CI-провайдера |
1 день |
YAML/UI настройка GitHub Actions, Codemagic или Bitrise, кэширование |
| Тестирование пайплайна |
1–2 дня |
Прогон 3–5 полных циклов сборки и деплоя, исправление ошибок |
| Документация и обучение |
0.5 дня |
Описание процесса, передача команде, 2-часовой воркшоп |
Distribution: TestFlight, Firebase App Distribution, Diawi
Для внутреннего тестирования iOS — TestFlight через pilot (Fastlane) или App Store Connect API. Для быстрой раздачи ad-hoc сборок без TestFlight — Firebase App Distribution (iOS + Android) или Diawi.
Firebase App Distribution удобен для Android: загружаешь APK/AAB, указываешь email тестеров, они получают ссылку. На iOS ограничен ad-hoc профилями — UDID устройств нужно добавлять вручную, что неудобно для больших групп тестировщиков. Если команда тестирования больше 10 человек, мы рекомендуем TestFlight с внешними группами: он не требует добавления UDID.
Как настроить версионирование без ошибок?
Правило: каждая сборка, ушедшая на TestFlight или в Firebase, должна иметь уникальный build number и быть привязана к git-тегу. agvtool или xcrun agvtool next-version -all в Fastlane через increment_build_number(xcodeproj:) с номером из CI build counter решает это автоматически.
Чек-лист типичных ошибок при настройке версионирования:
- Номер build number не совпадает с CI build ID — теряется связь сборка-коммит.
- Git tag ставится только на master, а не на каждый beta-релиз — невозможно откатиться на конкретную сборку.
- Версия маркетинга (CFBundleShortVersionString) не обновляется вручную — TestFlight показывает старое значение.
Что входит в работу
Мы настраиваем CI/CD под ключ, и в результате вы получаете:
- Рабочий Fastfile с ленами dev/staging/production с автоматическим инкрементом версии, code signing через
match и деплоем в TestFlight/Google Play.
- Конфигурации для GitHub Actions или Codemagic (на выбор): YAML-файлы с кэшированием, параллельными джобами, уведомлениями в Slack.
- App Store Connect API Key и настройка push-уведомлений (APNs/FCM).
- Документацию по запуску сборок и обновлению сертификатов.
- Обучение команды: 2 часа онлайн-воркшопа по работе с пайплайном.
- Пост-релизную поддержку в течение 14 дней (исправление возможных ошибок).
Почему стоит доверить настройку нам?
Мы — команда мобильных разработчиков с 5+ годами опыта в CI/CD. За это время реализовали 50+ проектов для iOS, Android и кроссплатформы. Настроенные нами пайплайны экономят командам от 8 до 12 часов в неделю на ручных операциях. У нас есть сертификаты Apple Developer, Google Play Console и опыт работы с корпоративными аккаунтами. Инвестиция в настройку окупается за 2–3 месяца — средняя экономия составляет $2500 в месяц за счёт отказа от ручных релизов и снижения числа ошибок.
Сроки и стоимость
Базовый CI/CD пайплайн с автосборкой и раздачей в TestFlight/Firebase — от 3 до 5 рабочих дней. Полная автоматизация с несколькими окружениями (dev/staging/production), автоматическим тестированием и ветвлением по git flow — 2–3 недели. Стоимость рассчитывается индивидуально исходя из сложности проекта и используемого стека. Закажите аудит текущего пайплайна — мы бесплатно оценим объём работ и предложим оптимальное решение. Получите консультацию — свяжитесь с нами.
Для справки: Wikipedia: CI/CD, официальная документация Fastlane.