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