Part-time

B2C-приложение: Настройка сборки и CI

май 2026 → сен 2026 (NDA)

Унаследованное приложение для людей с атопическим дерматитом: план ухода, опросник POEM, триггеры, фотоальбомы кожи и отчёты для врача. Оно живёт с 2020 года на MVVM, Koin, Room и Retrofit. До моего прихода сборка держалась на Groovy-скриптах с версиями в ext, а CI не было вовсе.

Мою часть можно описать одной фразой: я привёл сборку в порядок. Перевёл зависимости на version catalog, вынес общую настройку в convention-плагины, развёл окружения по флейворам и типам сборки, а потом собрал вокруг этого GitLab CI, где тег запускает нужную сборку и отправляет её в Telegram. Код самого приложения почти не трогал.

Part-time

v1.0.15-ruInternal

JIRA

APK

12:30

ARuDebug

ARuInternal

AComInternal

AApp

1.0.15-ruInternal

12:30

Формат: Part-time
Роль: Старший Android-разработчик
Период: май 2026 → сен 2026 (NDA)
Компания: KODE
Платформа: Android

Что я делал

Зависимости и репозитории
От ext-скриптов к version catalog
- Зависимости лежали в отдельном dependencies.gradle: 150 строк с переменными версий и списками, которые потом склеивались в ext. Я перенёс всё в gradle/libs.versions.toml: версии, библиотеки, плагины и бандлы (сеть, навигация, CameraX, Firebase и другие).
- Модули теперь подключают бандл одной строкой, а версия каждой библиотеки записана в одном месте. Плагины приложения (serialization, safeargs, google-services, Crashlytics, ktlint) тоже берутся из каталога.
- Репозитории я убрал из build.gradle и подпроектов и объявил один раз в settings.gradle. Режим FAIL_ON_PROJECT_REPOS не даёт модулю тихо добавить свой. Внутренний Maven стоит первым, а JitPack пускается только за группами com.github, чтобы чужие артефакты не подменяли свои.
- Подключил удалённый кэш Gradle: писать в него может только CI, а у разработчиков он работает на чтение. Локальный кэш выключен, потому что с kapt он давал странные результаты, об этом оставлен комментарий. Чтобы кэш не отдавал битые ресурсы, добавил cache-fix plugin.
dependencies.gradle
ext {
def retrofit = "…"
def okhttp = "…"
def room = "…"
kotlinDependencies = [
"…:${kotlin}"
}
libs.versions.toml
[versions]
retrofit = …
[libraries]
okhttp = { … }
[plugins]
google-services
[bundles]
network = [ … ]
implementation libs.bundles.network
✓ FAIL_ON_PROJECT_REPOS · репозитории только в settings
Convention-плагины
Общая настройка в одном месте
- В android-app-convention лежит всё общее для приложения: compileSdk 36, buildTools 36.0.0, minSdk 24, Java 17 и toolchain, отключённые aidl и renderScript, JUnit Platform с подробным логом упавших и пропущенных тестов.
- Модули-библиотеки после этого стали совсем короткими. Например, convention для библиотек занимает четыре строки: подключить com.android.library и общую настройку, а у koin-convention остаётся одна зависимость.
- Плагины ставятся с оговорками, которые стоит знать. Groovy-скрипт не умеет alias(libs...) в блоке plugins, поэтому версии плагинов задаются зависимостями в build-convensions/build.gradle. Рядом оставлен обход проблемы KSP, где kapt ждёт kspKotlin: по ссылке на issue его можно будет убрать.
feature/<name> · набор соседнего проекта команды
domainkotlincompose
dataandroid-librarydaggeropenapicompose
uiandroid-librarycomposedagger
appandroid-appdaggercompose
compose только там, где есть UI
Флейворы и типы сборки
Шесть вариантов из двух версий и трёх типов
- У приложения две версии: ru и com, у каждой свой бэкенд, свой Firebase и свой набор ресурсов. Я переименовал флейворы из ruVersion и comVersion в короткие ru и com, перенёс за ними исходники, схемы Room и google-services.json и поправил ссылки в нескольких Kotlin-файлах.
- К ним добавил три типа сборки: debug, internal и release. Получилось шесть вариантов. Debug для разработки, internal для тестировщиков (минификация включена, но подписан отладочным ключом), release для магазина.
- Адрес сервера для каждой пары флейвор и тип лежит в одной таблице и попадает в BuildConfig автоматически. Для internal я добавил свои адреса: debug и internal смотрят на staging, release на боевой сервер.
- У debug и internal теперь свои applicationId с суффиксами .dev и .internal. До этого у всех типов одного флейвора был один пакет, и это ломало установку: release поверх internal предлагал обновление, а оно падало, потому что internal подписан отладочным ключом, а release ключом загрузки.
- Название под иконкой тоже зависит от варианта. У release оно остаётся обычным, а у остальных пишется флейвор и тип, и на телефоне сразу видно, какая сборка перед тобой. Тестировщики могут держать на одном устройстве все варианты рядом.
- Chucker подключён по-разному: в debug и internal он настоящий, чтобы смотреть трафик, а в release это заглушка. Нужна она потому, что код во флейвор-папках ссылается на Chucker для всех типов, а R8 потом выбрасывает заглушку.
debuginternalrelease
ru
.dev
staging
.internal
staging
·
prod
com
.dev
staging
.internal
staging
·
prod
все шесть ставятся рядом
Версия из тега
Номер сборки и имя варианта в самом приложении
- Версию больше никто не правит руками. Тег вида v1.0.15-comRelease плагин build-publish-novo разбирает сам: 1.0.15 становится версией, 15 номером сборки, а хвост после дефиса именем варианта.
- Я выбрал стратегию, при которой в versionName попадает вариант целиком, то есть 1.0.15-comRelease. Тогда сборку можно опознать прямо на устройстве, в настройках приложения, не открывая код и не спрашивая тестировщика.
- versionCode остаётся номером сборки из тега, поэтому он растёт вместе с номером в теге.
- Из build.gradle я убрал versionCode и versionName. С тегом они всё равно берутся из него, а без тега плагин подставляет заглушку 1 и «0.0». Так локальная сборка в IDE не требует никаких настроек, и в файле остался комментарий, почему поля удалены.
- Имя APK тоже строит плагин: базовое имя задано в конфиге, а версию и вариант он подставляет из тега.
git tag
v1.0.15-comRelease
версия · сборкавариант
▾
versionName1.0.15-comRelease
versionCode15
APK…-1.0.15-comRelease.apk
GitLab CI
Тег запускает ровно ту сборку, которая нужна
- До этого в проекте не было CI совсем. Я собрал пайплайн из трёх стадий: подготовка (секреты и скрипты), сборка и служебные задачи. Общие шаблоны для раннеров, образов и правил берутся из ci-toolkit компании, а проектный конфиг пишется поверх.
- Обычная сборка делает debug, а до неё отдельная задача прогревает кэш Gradle. Размеры памяти для Gradle и Kotlin-демона вынесены в переменные, а таймауты сети Gradle увеличены.
- Релизы устроены через теги. Сначала было две общие задачи, internal и release, но флейворов два, и собирать оба каждый раз незачем. Поэтому теперь четыре отдельных задачи: com и ru, internal и release. Каждая срабатывает только на свой тег по регулярке вроде /-comInternal$/ и собирает только свой вариант.
- В релизных задачах кроме APK собирается и AAB для магазина. В артефакты уходят APK, AAB, лог сборки, лог памяти и mapping.txt: без него нельзя разобрать крэши из Crashlytics.
- Для тегов стоит GIT_DEPTH 0: плагину нужна полная история, чтобы читать теги и коммиты. А у internal-задач отключён build scan.
подготовка›сборка›служебные
⌥v1.0.15-ruRelease
com-internal/-comInternal$/
ru-internal/-ruInternal$/
com-release/-comRelease$/
ru-release/-ruRelease$/✓
APKAABmapping.txtlogs
Публикация в Telegram
Сборка и changelog приходят в чат сами
- Тестировщикам не нужно ходить в GitLab за файлом. После сборки в чат «builds» приходит сообщение со списком изменений, а следом сам APK, а для релиза ещё и AAB. Отправляет их бот на нашем сервере через плагин build-publish-novo.
- Список изменений собирается из коммитов. В сообщении коммита ищется ключ CHANGELOG, а номер задачи по шаблону превращается в ссылку на Jira. Если в коммите нет задачи, ничего не ломается: шаблон безобидный.
- Плагин читает настройки бота при конфигурации, то есть при каждой синхронизации проекта в IDE. Если требовать переменные окружения всегда, у любого разработчика без секретов сборка не запустится. Поэтому я проверяю их только когда в задачах есть слово telegram. На обычной сборке подставляется пустая строка, и ничего не публикуется.
- Тема чата необязательна: если это форум, ID темы берётся из переменной, а если простой чат, остаётся пустым. Упоминания людей тоже приходят из переменной списком.
- Плагин только регистрирует задачи Telegram, а сам не вызывает. Сначала сборки ничего не отправляли, потому что в GRADLE_TASKS были только assemble и bundle. Теперь для каждого из четырёх вариантов дописаны sendTelegramChangelog и telegramDistributionUpload.
✓assembleRuRelease
✓sendTelegramChangelog…
✓telegramDistributionUpload…
секреты проверяются, только если в задачах есть telegram
v1.0.15-ruRelease
JIRA
JIRA
JIRA
APKAAB
Сеть и отладка трафика
Прокси работает там, где нужно, и не работает в релизе
- Тестировщикам и разработчикам нужно смотреть HTTPS-трафик через Proxyman или Charles. Для этого приложение должно доверять пользовательским сертификатам, но в магазинной сборке этого быть не должно.
- Настроил network-security-config для каждого типа сборки отдельно. В debug и internal (src/debug и src/internal) приложение доверяет пользовательским сертификатам, поэтому тестировщики и разработчики видят HTTPS-трафик в Proxyman или Charles. В release (main) остались только системные сертификаты.
- Internal-сборка не зависит от флага debuggable: разрешение выдаётся самим конфигом. Файлы debug и internal синхронизируются между собой, об этом оставлен комментарий. Cleartext везде запрещён, кроме localhost.
- Конфиг выбирается по типу сборки через обычные source sets, поэтому в манифесте нет никаких условий. Пользовательские сертификаты в магазинную сборку попасть не могут.
proxycert
debugсистемные + пользовательские✓
internalсистемные + пользовательские✓
releaseтолько системные✕
src/debug · src/internal → base-config
src/main (release) → system
Окружения и Firebase
Тестовые сборки больше не шлют данные в боевой проект
- Разделил окружения в Firebase: debug и internal отправляют крэши и аналитику в тестовые клиенты, и только release пишет в боевой проект. Данные тестовых сборок больше не смешиваются с данными реальных пользователей.
- Вместо четырёх Firebase-проектов (по два на флейвор) оставил два, по одному на флейвор. В каждом три приложения: боевой пакет, .dev и .internal. Нужное приложение плагин выбирает сам по applicationId.
- Зарегистрировал новые пакеты в Firebase Console, перевыпустил конфиги и положил их в сборку.
- Перенёс по очереди флейворы ru и com и проверил каждый вариант: debug и internal видят staging-клиенты, release боевой.
- Адреса серверов по вариантам лежат в одной таблице в app/build.gradle. При конфигурации Gradle печатает в лог, какой адрес выбран для каждого варианта, поэтому окружение видно сразу.
было
ru stageru prodcom stagecom prod
▾
стало
ru
.dev.internalrelease
com
.dev.internalrelease

Стек проекта

Языки

Groovy (Gradle)
Kotlin

Сборка

Gradle
Version Catalog (TOML)
Convention-плагины
Android Gradle Plugin 8.6
Remote build cache
Develocity
cache-fix plugin
R8 / ProGuard

CI и выпуск

GitLab CI
ci-toolkit (общие шаблоны)
Сборки по тегам
build-publish-novo
Telegram bot
Jira changelog

Окружения

Флейворы ru / com
Типы debug / internal / release
Firebase Crashlytics и Analytics
Chucker
Network Security Config

Само приложение (до меня)

Kotlin 2.0
MVVM
Koin
Room
Retrofit и OkHttp
Navigation
ViewBinding и DataBinding
CameraX
Glide
PushWoosh
AppMetrica

Что я делал

Зависимости и репозитории

Convention-плагины

Флейворы и типы сборки

Версия из тега

GitLab CI

Публикация в Telegram

Сеть и отладка трафика

Окружения и Firebase

Стек проекта

Языки

Сборка

CI и выпуск

Окружения

Само приложение (до меня)

Что я делал

Зависимости и репозитории

Convention-плагины

Флейворы и типы сборки

Версия из тега

GitLab CI

Публикация в Telegram

Сеть и отладка трафика

Окружения и Firebase

Стек проекта

Языки

Сборка

CI и выпуск

Окружения

Само приложение (до меня)