Internal Testing Track в Google Play: налаштування треку

Що таке Internal Testing Track?

Internal Testing Track — перший рівень тестування в Google Play Console, призначений для поширення збірок у середині команди розробників. Основна мета — швидка перевірка працездатності, тестування інтеграцій та виявлення критичних помилок до розширення аудиторії на Closed або Open треки.

На відміну від інших треків Google Play, Internal Testing не потребує перевірки Google перед активацією. Збірка стає доступною тестувальникам протягом кількох хвилин після завантаження в консоль. Це робить трек ідеальним для щоденних збірок (daily builds) та автоматичної доставки з CI/CD пайплайну.

За даними документації Google Play Console (2024), Internal Testing Track підтримує два варіанти поширення: список email (до 100 учасників) та Google Groups (без обмеження за кількістю). Групи підходять для великих команд, де учасники змінюються частіше, а email найкраще підходить для фіксованого складу розробників.

Коли обирати Internal Testing Track

Internal трек обирають на ранніх етапах розробки, коли додаток ще нестабільний, а API можуть змінюватися. Пайплайн CI/CD завантажує кожну нову збірку в Internal трек, і команда отримує найновішу версію негайно. Помилки та логи крашів збираються через Play Console до того, як збірка потрапить до зовнішніх тестувальників або користувачів.

Для нових акаунтів розробників Internal Testing Track служить першим кроком підготовки до публікації. Google не перевіряє збірки на цьому етапі, що дозволяє команді самостійно переконатися в якості продукту перед передачею на ревю.

Як налаштувати Internal Testing Track в Google Play Console

Налаштування Internal Testing Track виконується в Google Play Console у розділі Release > Testing > Internal Testing. Процес включає створення треку, завантаження першої збірки та додавання тестувальників.

Щоб створити трек, перейдіть в розділ Internal Testing та натисніть Create track. Після створення треку система запропонує завантажити першу збірку у форматі AAB (Android App Bundle). Google рекомендує AAB для всіх типів тестування, оскільки формат оптимізує розмір додатку відповідно до архітектури пристрою.

Після завантаження збірки доступ до треку відкривається додаванням тестувальників. Без хоча б одного тестувальника трек не вважається активним. Google Play Console показує статус треку, список завантажених збірок та статистику встановлень для кожного учасника.

// build.gradle - автоматичне завантаження в Internal Testing Track
android {
    def versionCode = System.env.GIT_COMMIT_COUNT ?: "1"
    def versionName = "1.0." + versionCode

    defaultConfig {
        versionCode versionCode.toInteger()
        versionName versionName
    }
}

// Розгортання через плагін Gradle Play Publisher
plugins {
    id 'com.github.triplet.play' version '3.9.0'
}

play {
    track = "internal"
    serviceAccountCredentials = file("play-account.json")
}

Додавання тестувальників в Internal трек

Додавання тестувальників в Internal Testing Track можливе двома способами: за email та через Google Groups. Список email підходить для невеликих команд з фіксованим складом. Кожен тестувальник додається вручну в консолі та отримує запрошення на вказану адресу.

Google Groups переважні для команд зі змінним складом або автоматизованим керуванням доступом. Достатньо додати групу в трек, і всі її учасники отримують доступ до збірок. Зміна складу групи відбувається без оновлення налаштувань в Play Console.

Тестувальники встановлюють додаток через Google Play на пристрої. Після додавання в трек вони бачать додаток як доступний для оновлення (якщо раніше встановлювали його з іншого треку) або як новий додаток для встановлення. Збірки з Internal треку не публікуються в загальному доступі — їх бачать лише учасники треку.

Збір метрик в Internal треку

Google Play автоматично збирає Android Vitals для всіх збірок в Internal Testing Track: частоту крашів, ANR та час запуску. Розробник бачить метрики в Play Console одразу після встановлення збірки першим тестувальником. Дані доступні в реальному часі без затримок на агрегацію.

Відмінності Internal Testing від Closed та Open треків

Internal Testing Track відрізняється від Closed та Open треків за швидкістю доступу, вимогами до перевірки та масштабом аудиторії. Internal не потребує модерації, Closed потребує налаштування Google Groups та перевірки, Open проходить повну перевірку Google.

Internal трек єдиний, де збірка доступна без очікування. Closed та Open потребують перевірки Google, яка займає від кількох годин до 2 днів. Для нових акаунтів розробників Open Testing Track обов’язковий: додаток повинен пройти 14-денне відкрите тестування перед публікацією в продакшн.

Автоматизація Internal Testing через CI/CD

Автоматизація завантаження в Internal Testing Track — стандартна практика для CI/CD пайплайнів Android-проектів. Gradle Play Publisher — найпопулярніший плагін для автоматичної публікації збірок. Він підписує AAB, завантажує його в Google Play та призначає трек.

Fastlane надає дію supply для завантаження збірок в Play Console. Параметр track вказує цільовий трек: internal, closedalpha, openbeta або production. Керування версіями та сервісний акаунт налаштовуються один раз у Fastfile.

# Fastfile - автоматизоване завантаження в Internal Testing Track
platform :android do
    desc "Build and deploy to Internal Testing"
    lane :internal do
        gradle(task: "bundleRelease")
        supply(
            track: "internal",
            aab: "app/build/outputs/bundle/release/app-release.aab",
            skip_upload_metadata: true,
            skip_upload_images: true
        )
    end
end

Сервісний акаунт Google Play створюється в Google Cloud Console з роллю Publisher та прив’язується до акаунта розробника в Play Console. JSON-ключ сервісного акаунта зберігається в репозиторії CI/CD як захищена змінна (GitHub Secrets, GitLab CI Variables, Jenkins Credentials).