Настройка CI/CD для Android-приложения через Gradle

Настройка CI/CD для Android поднимает больше вопросов, чем кажется. Частая ситуация: разработчик пушит код, CI падает с ошибкой "Keystore not found" или сборка длится 15 минут, а релиз задерживается на день. Недавно команда из 5 разработчиков обратилась к нам: их сборка длилась 30 минут, релиз выходил раз в две недели. После внедрения CI/CD с Gradle кэшированием и параллельной сборкой время сократилось до 10 минут, частота релизов выросла до еженедельных. Сокращение времени сборки напрямую снижает затраты на CI-раннеры и ускоряет выход обновлений, что экономит бюджет команды.

Основные грабли: keystore в репозитории, ручное версионирование, отсутствие кэша на CI, неправильная конфигурация build variants. Каждая из этих ошибок способна заблокировать релиз или привести к утечке секретов. Наша услуга по настройке CI/CD включает полный аудит текущей сборки, конфигурацию Gradle с учётом лучших практик, интеграцию с CI-системой и деплой в Google Play. Инвестиции в настройку CI/CD окупаются за счёт ускорения релизного цикла и снижения ручного труда. Гарантируем стабильную работу после внедрения.

Как правильно подписать APK в CI?

Keystore в Git — критическая ошибка, даже в приватном репозитории. Правильная схема: keystore Base64-encoded → CI secret → декодируем на лету.

# GitHub Actions
- name: Decode Keystore
  run: |
    echo "${{ secrets.KEYSTORE_BASE64 }}" | base64 --decode > app/release.keystore

- name: Build Release AAB
  run: ./gradlew bundleRelease
  env:
    SIGNING_STORE_FILE: release.keystore
    SIGNING_STORE_PASSWORD: ${{ secrets.KEYSTORE_PASSWORD }}
    SIGNING_KEY_ALIAS: ${{ secrets.KEY_ALIAS }}
    SIGNING_KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }}

В app/build.gradle.kts:

signingConfigs {
    create("release") {
        storeFile = file(System.getenv("SIGNING_STORE_FILE") ?: "debug.keystore")
        storePassword = System.getenv("SIGNING_STORE_PASSWORD") ?: ""
        keyAlias = System.getenv("SIGNING_KEY_ALIAS") ?: ""
        keyPassword = System.getenv("SIGNING_KEY_PASSWORD") ?: ""
    }
}

buildTypes {
    release {
        signingConfig = signingConfigs.getByName("release")
        isMinifyEnabled = true
        proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
    }
}

Keystore не попадает в артефакты — после сборки удаляем: rm -f app/release.keystore.

Процесс состоит из нескольких шагов:

1. Загрузите keystore в CI secrets в виде Base64-строки.
2. Создайте job для декодирования и сборки.
3. Настройте signingConfig в build.gradle.kts с использованием переменных окружения.
4. После сборки удалите keystore из файловой системы.

Почему автоматическое версионирование — стандарт?

versionCode в Android должен быть уникальным для каждой сборки. Ошибка — использовать ручное обновление. На CI — автоматически:

// build.gradle.kts
val ciPipelineNumber = System.getenv("CI_BUILD_NUMBER")?.toIntOrNull() ?: 1
val gitCommitCount = "git rev-list --count HEAD".runCommand().trim().toIntOrNull() ?: 1

android {
    defaultConfig {
        versionCode = ciPipelineNumber.takeIf { it > 1 } ?: gitCommitCount
        versionName = "2.4.${gitCommitCount}"
    }
}

Сравнение методов:

Рекомендуем git commit count — не привязан к CI-системе.

Как ускорить Gradle сборку?

Медленный Gradle — главная жалоба Android CI. Несколько конкретных настроек в gradle.properties:

• org.gradle.parallel=true — параллельная сборка модулей.
• org.gradle.configureondemand=true — конфигурирование только нужных модулей.
• org.gradle.caching=true — локальный кэш задач. При неизменном коде модуля Gradle берёт результат из кэша без перекомпиляции. На CI это работает через actions/cache (GitHub) с ключом по хэшу *.gradle* файлов.
• org.gradle.jvmargs=-Xmx4g -XX:+UseParallelGC — увеличенный heap.
• android.defaults.buildfeatures.buildconfig=false — генерация BuildConfig только для активной сборки.

Подробнее о настройке кэша — в Gradle Build Cache.

Сравнение времени сборки с разными конфигурациями на ubuntu-latest раннере:

Правильное кэширование сокращает время в 3-4 раза. Используйте R8 вместо ProGuard — он быстрее.

Какие build variants настраивать?

Разные variant-ы для разных окружений — стандарт:

flavorDimensions += "env"
productFlavors {
    create("dev") {
        applicationIdSuffix = ".dev"
        buildConfigField("String", "API_URL", "\"https://api.dev.example.com\"")
    }
    create("prod") {
        buildConfigField("String", "API_URL", "\"https://api.example.com\"")
    }
}

На CI — separate jobs для каждого variant-а:

• PR → assembleDevDebug + тесты
• merge to develop → assembleDevRelease + Firebase App Distribution
• release tag → bundleProdRelease + Google Play

Загрузка в Google Play через Gradle

gradle-play-publisher plugin:

// build.gradle.kts
plugins {
    id("com.github.triplet.play") version "3.9.1"
}

play {
    serviceAccountCredentials.set(file(System.getenv("PLAY_STORE_JSON") ?: "play-store-credentials.json"))
    track.set("internal")
    defaultToAppBundles.set(true)
}

Credentials JSON — service account из Google Play Console с доступом Release manager. На CI передаём через environment variable, аналогично keystore.

Что входит в настройку CI/CD?

Сроки

Базовая настройка CI/CD (подписание, версионирование, один CI) занимает 2–4 дня. Полная конфигурация с build variants, деплоем в Google Play, оптимизацией сборки — 1–2 недели. Стоимость рассчитывается индивидуально.

Если ваша сборка занимает слишком много времени или релизы постоянно срываются, пора внедрить профессиональный CI/CD. Свяжитесь с нами — мы проведём аудит и настроим процесс, чтобы вы забыли о релизных проблемах. Гарантируем стабильный результат.

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 выполните шаги:

1. Создайте YAML-файл в .github/workflows/
2. Настройте секреты репозитория: MATCH_PASSWORD, ASC_API_KEY (ключ в JSON)
3. Укажите runs-on: macos-14
4. Используйте ruby/setup-ruby@v1 с bundler-cache: true
5. Запустите 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 разработчиков.

Основные этапы настройки CI/CD

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.