Шаг 1: Подготовка кодовой базы и конфигураций. Прежде чем что-либо деплоить, необходимо разделить конфигурации для разных сред (debug, staging, production). Никогда не храните секреты (ключи API, пароли) и финальные keystore в репозитории. Используйте механизмы, предоставляемые Gradle, в связке с файлами свойств или переменными окружения CI-системы. Создайте `keystore.properties` файл, который будет исключен из git (добавьте в `.gitignore`), и загружайте его в безопасное хранилище вашей CI-системы (например, Secrets в GitHub Actions или Secure Files в GitLab CI). В `build.gradle` модуля app настройте чтение этих свойств:
android {
signingConfigs {
release {
storeFile file(System.getenv("RELEASE_STORE_FILE") ?: "default_path.jks")
storePassword System.getenv("RELEASE_STORE_PASSWORD") ?: ""
keyAlias System.getenv("RELEASE_KEY_ALIAS") ?: ""
keyPassword System.getenv("RELEASE_KEY_PASSWORD") ?: ""
}
}
buildTypes {
release {
signingConfig signingConfigs.release
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
}
}
Шаг 2: Настройка непрерывной интеграции (CI). Выберите CI-систему (Jenkins, GitHub Actions, GitLab CI, Bitrise). Профессиональный подход предполагает создание конвейера, который запускается автоматически при пуше в определенные ветки (например, `main`/`master` для продакшена, `develop` для стаджинга). Конвейер должен выполнять следующие задачи: 1) Проверка кода (lint, detekt, ktlint). 2) Запуск unit- и instrumented-тестов на эмуляторах или реальных устройствах в облаке (Firebase Test Lab, AWS Device Farm). 3) Сборка release-версии приложения с использованием секретов из хранилища CI. 4) Генерация отладочной информации (mapping файл для ProGuard/R8) и ее сохранение как артефакт сборки.
Пример фрагмента `gitlab-ci.yml` для стадии сборки:
build_release:
stage: build
script:
- echo $RELEASE_KEYSTORE_BASE64 | base64 --decode > app/keystore.jks
- export RELEASE_STORE_FILE=app/keystore.jks
- export RELEASE_STORE_PASSWORD=$KEYSTORE_PASSWORD
- export RELEASE_KEY_ALIAS=$KEY_ALIAS
- export RELEASE_KEY_PASSWORD=$KEY_PASSWORD
- ./gradlew assembleRelease
artifacts:
paths:
- app/build/outputs/apk/release/app-release.apk
- app/build/outputs/mapping/release/mapping.txt
expire_in: 1 week
only:
- main
- tags
Шаг 3: Автоматическое управление версиями. Версии кода (versionCode) и имени (versionName) должны увеличиваться автоматически. Для versionCode можно использовать номер сборки из CI (например, `CI_PIPELINE_IID` в GitLab). Для versionName можно использовать семантическое версионирование на основе git-тегов. Плагины вроде `gradle-git-versioner` или скрипты на Groovy/Kotlin могут автоматически вычислять эти значения, исключая человеческий фактор.
Шаг 4: Подписывание и выравнивание (zipalign) APK или создание Android App Bundle (AAB). Начиная с августа 2021 года, публикация новых приложений в Google Play Console требует формат Android App Bundle. Он обеспечивает оптимизацию размера за счет генерации раздельных APK для разных конфигураций устройств. Сборка AAB выполняется таском `bundleRelease`. Подписывание AAB происходит автоматически, если настроен `signingConfig` для release, как показано выше. Для сторонних магазинов или корпоративного распространения может потребоваться APK. Используйте `zipalign` (он уже входит в вызов `assembleRelease`) для оптимизации.
Шаг 5: Распространение (Distribution). После успешной сборки артефакт должен быть доставлен в целевую среду.
- Для внутреннего тестирования и стаджинга: используйте сервисы вроде Firebase App Distribution, Microsoft App Center или собственный хостинг с простой скачиваемой ссылкой. Интегрируйте загрузку в CI-конвейер.
- Для продакшена в Google Play: используйте Google Play API (библиотека `gradle-play-publisher`) для полностью автоматизированной публикации в альфа/бета/продакшен-треки. Это позволяет загружать AAB, управлять описаниями и даже продвигать сборки по трекам без ручного входа в консоль.
- name: Publish to Play Store
RELEASE_KEYSTORE_BASE64: ${{ secrets.RELEASE_KEYSTORE_BASE64 }}
# ... другие секреты
PLAY_STORE_CREDENTIALS: ${{ secrets.PLAY_STORE_SERVICE_ACCOUNT_JSON }}
Шаг 6: Пост-деплой мониторинг и обратная связь. Развертывание не заканчивается на публикации в магазин. Необходимо настроить сбор крашей и аналитики.
- Интегрируйте Firebase Crashlytics для получения отчетов об аварийных завершениях. Обязательно загружайте mapping-файл (сгенерированный на шаге 2) в Crashlytics, чтобы деобфусцировать стек-трейсы.
- Используйте Google Analytics или Firebase Analytics для отслеживания ключевых метрик: количество установок, активных пользователей, производительности (например, время запуска приложения).
- Настройте оповещения (alerts) на критическое количество крашей или падение ключевых бизнес-показателей после релиза новой версии.
Шаг 8: Документация и коммуникация. Автоматически генерируйте changelog на основе коммитов между тегами и прикрепляйте его к релизу в Play Console и внутренним уведомлениям для команды тестирования. Используйте инструменты вроде `conventional-changelog`.
Заключение: Профессиональное развертывание Android — это создание надежного, «защищенного от дурака» конвейера, который минимизирует ручной труд, исключает ошибки подписывания и управления версиями, обеспечивает быструю обратную связь о стабильности релиза и позволяет оперативно реагировать на инциденты. Инвестиции в настройку такого процесса окупаются повышением скорости доставки фич, снижением стресса команды и улучшением качества продукта для конечного пользователя.
Комментарии (17)