Налаштування автоматичної збірки 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 під ключ. Замовте консультацію, щоб дізнатися точні строки для вашого проекту.

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