Настройка автоматической сборки Android-приложения (Build Automation)

Настройка автоматической сборки Android-приложения (Build Automation)

Мы часто видим, как разработчики жалуются на долгую сборку в CI: проект с 15+ модулями, Gradle работает на одном потоке, холодная сборка 4–7 минут, инкрементальная — 90 секунд. В команде из 10 человек это превращается в очередь билдов, блокирующую ревью. Наш опыт показывает, что правильная автоматизация сборки — не панацея, а системная работа с конфигами Gradle, CI-пайплайном и кэшированием. Настраиваем всё так, чтобы билд проходил на любой машине стабильно и без ручных шагов.

Основные точки боли при Android Build Automation

Как безопасно подписывать APK/AAB в CI?

Самая частая проблема. Разработчики хранят keystore в репозитории (плохо) или передают через аргументы командной строки открытым текстом (ещё хуже). Правильная схема: keystore кодируется в Base64, кладётся в переменную окружения CI, перед сборкой декодируется во временный файл, после сборки — удаляется. В build.gradle.kts это конфигурируется через переменные окружения:

android {
    signingConfigs {
        create("release") {
            storeFile = file(System.getenv("KEYSTORE_PATH") ?: "debug.keystore")
            storePassword = System.getenv("KEYSTORE_PASSWORD") ?: "android"
            keyAlias = System.getenv("KEY_ALIAS") ?: "androiddebugkey"
            keyPassword = System.getenv("KEY_PASSWORD") ?: "android"
        }
    }
    buildTypes {
        release {
            signingConfig = signingConfigs.getByName("release")
            isMinifyEnabled = true
            proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
        }
    }
}

Конфигурация сборки по веткам

Второй болевой узел. main → release AAB для Play Store, develop → debug APK с тестовыми эндпоинтами, release/* → staging APK для QA. Реализуется через комбинацию buildFlavors + условия в CI-скрипте. Не нужно плодить отдельные build.gradle файлы — достаточно одной конфигурации с flavorDimensions.

Почему важно кэширование Gradle?

Без кэша CI качает 200–400 МБ зависимостей при каждом запуске. С правильным кэшированием ~/.gradle/caches и ~/.gradle/wrapper первая сборка после изменения build.gradle занимает полное время, остальные — инкрементально. В среднем экономия ~60% времени сборки после первого билда. Мы используем remote build cache (через S3) для распределённых команд.

Как настраиваем

Базовый стек: Gradle 8.x + AGP 8.x + GitHub Actions / GitLab CI / Bitrise. Fastlane используем для задач, которые Gradle не умеет из коробки: загрузка в Google Play через supply, отправка уведомлений, управление треками (internal → alpha → production).

Структура типичного CI-пайплайна (GitHub Actions):

# .github/workflows/android-release.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
      - name: Cache Gradle
        uses: actions/cache@v4
        with:
          path: |
            ~/.gradle/caches
            ~/.gradle/wrapper
          key: gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
      - name: Decode Keystore
        run: echo "$KEYSTORE_BASE64" | base64 -d > app/release.keystore
        env:
          KEYSTORE_BASE64: ${{ secrets.KEYSTORE_BASE64 }}
      - name: Build Release AAB
        run: ./gradlew bundleRelease
        env:
          KEYSTORE_PATH: release.keystore
          KEYSTORE_PASSWORD: ${{ secrets.KEYSTORE_PASSWORD }}
          KEY_ALIAS: ${{ secrets.KEY_ALIAS }}
          KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }}
      - name: Upload Artifact
        uses: actions/upload-artifact@v4
        with:
          name: release-aab
          path: app/build/outputs/bundle/release/app-release.aab

Отдельно настраиваем gradle.properties под CI: org.gradle.daemon=false (демон в CI не нужен), org.gradle.parallel=true, org.gradle.configureondemand=true. На проектах с несколькими модулями это сокращает время конфигурации на 30–40%.

Параллельные задачи и оптимизация

Если проект монолитный, параллелизация почти не даёт эффекта. Но при модульной архитектуре (:core, :feature-auth, :feature-feed, :app) Gradle строит граф зависимостей и собирает независимые модули параллельно. ./gradlew assembleDebug --parallel на 8-ядерном агенте даёт выигрыш в 2–3 раза по сравнению с последовательной сборкой.

Для больших команд подключаем Gradle Build Cache — либо через Gradle Enterprise (платно), либо через открытое решение с S3 бэкендом.

Gradle User Manual рекомендует комбинировать оба подхода.

Сравнение CI-платформ для Android

Что входит в работу

• Аудит текущего build.gradle (Groovy → Kotlin DSL, версии плагинов, неоптимальные конфиги)
• Настройка signing config через переменные окружения CI
• CI-пайплайн под вашу платформу (GitHub Actions, GitLab CI, Bitrise)
• Кэширование Gradle (локальное и remote)
• Конфигурация по веткам с помощью build flavors
• Документация для команды и обучение разработчиков
• Гарантия стабильности — после сдачи всё работает без ручных донастроек

Процесс работы

1. Первичная консультация и анализ текущей сборки.
2. Перевод на современный Gradle + Kotlin DSL (если необходимо).
3. Настройка signing config через секреты CI.
4. Создание CI-конфигурации с кэшированием и параллельностью.
5. Тестирование на нескольких ветках (main, develop, release/).
6. Документирование и передача команде.

Стоимость рассчитывается индивидуально после анализа требований. Срок: 2–3 дня для одномодульного проекта, до 5 дней для многомодульного. Свяжитесь с нами для оценки вашего проекта — поможем внедрить build automation под ключ. Закажите консультацию, чтобы узнать точные сроки для вашего проекта.

Мы имеем более 5 лет опыта в Android-разработке и настроили пайплайны для 30+ проектов — от стартапов до enterprise-приложений. Наши инженеры следят за актуальными версиями Gradle и AGP, поэтому вы получаете современную конфигурацию без устаревших практик.