Internal Testing Track w Google Play: istota i konfiguracja ścieżki

Czym jest Internal Testing Track?

Internal Testing Track — pierwszy poziom testowania w Google Play Console, przeznaczony do rozpowszechniania kompilacji w zespole deweloperskim. Głównym celem jest szybkie sprawdzenie działania, testowanie integracji i wykrywanie krytycznych błędów przed rozszerzeniem odbiorców na ścieżki Closed lub Open.

W przeciwieństwie do innych ścieżek Google Play, Internal Testing nie wymaga weryfikacji Google przed aktywacją. Kompilacja staje się dostępna dla testerów w ciągu kilku minut po przesłaniu do konsoli. To czyni tę ścieżkę idealną do daily-buildu00f3w i automatycznej dostawy z pipeline CI/CD.

Według dokumentacji Google Play Console (2024), Internal Testing Track obsługuje dwa sposoby dystrybucji: listę e-mail (do 100 uczestnikóww) i Google Groups (bez ograniczeń liczbowych). Grupy są odpowiednie dla dużych zespołów, gdzie uczestnicy zmieniają się częściej, a e-mail — dla stałego składu deweloperów.

Kiedy wybrać Internal Testing Track

Ścieżkę Internal wybiera się na wczesnych etapach rozwoju, gdy aplikacja jest jeszcze niestabilna, a API mogą się zmieniać. Pipeline CI/CD przesyła każdą nową kompilację do ścieżki Internal, a zespół otrzymuje świeżą wersję natychmiast. Błędy i logi crashów są zbierane przez Play Console, zanim kompilacja trafi do zewnętrznych testerów lub użytkowników.

Dla nowych kont deweloperskich Internal Testing Track służy jako pierwszy etap przygotowania do publikacji. Google nie sprawdza kompilacji na tym etapie, co pozwala zespołowi samodzielnie upewnić się co do jakości produktu przed przekazaniem do recenzji.

Jak skonfigurować Internal Testing Track w Google Play Console

Konfiguracja Internal Testing Track odbywa się w Google Play Console w sekcji Release > Testing > Internal Testing. Proces obejmuje utworzenie ścieżki, przesłanie pierwszej kompilacji i dodanie testerów.

Aby utworzyć ścieżkę, przejdź do sekcji Internal Testing i kliknij Create track. Po utworzeniu ścieżki system poprosi o przesłanie pierwszej kompilacji w formacie AAB (Android App Bundle). Google zaleca AAB dla wszystkich typów testowania, ponieważ format optymalizuje rozmiar aplikacji pod architekturę urządzenia.

Po przesłaniu kompilacji dostęp do ścieżki otwiera się przez dodanie testerów. Bez co najmniej jednego testera ścieżka nie jest uważana za aktywną. Google Play Console pokazuje status ścieżki, listę przesłanych kompilacji i statystyki instalacji dla każdego uczestnika.

// build.gradle - automatyczne przesyłanie do Internal Testing Track
android {
    def versionCode = System.env.GIT_COMMIT_COUNT ?: "1"
    def versionName = "1.0." + versionCode

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

// Wdrożenie przez plugin Gradle Play Publisher
plugins {
    id 'com.github.triplet.play' version '3.9.0'
}

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

Dodawanie testerów do ścieżki Internal

Dodawanie testerów do Internal Testing Track jest możliwe na dwa sposoby: przez e-mail i przez Google Groups. Lista e-mail nadaje się dla małych zespołów ze stałym składem. Każdy tester jest dodawany ręcznie w konsoli i otrzymuje zaproszenie na podany adres.

Google Groups są preferowane dla zespołów ze zmiennym składem lub zautomatyzowanym zarządzaniem dostępem. Wystarczy dodać grupę do ścieżki, a wszyscy jej członkowie uzyskują dostęp do kompilacji. Zmiana składu grupy odbywa się bez aktualizacji ustawień w Play Console.

Testerzy instalują aplikację przez Google Play na urządzeniu. Po dodaniu do ścieżki widzą aplikację jako dostępną do aktualizacji (jeśli wcześniej instalowali ją z innej ścieżki) lub jako nową aplikację do instalacji. Kompilacje ze ścieżki Internal nie są publikowane publicznie — widzą je tylko uczestnicy ścieżki.

Zbieranie metryk w ścieżce Internal

Google Play automatycznie zbiera Android Vitals dla wszystkich kompilacji w Internal Testing Track: częstotliwość crashy, ANR i szybkość uruchamiania. Deweloper widzi metryki w Play Console natychmiast po instalacji kompilacji przez pierwszego testera. Dane są dostępne w czasie rzeczywistym bez opóźnień agregacji.

Różnice między Internal Testing a ścieżkami Closed i Open

Internal Testing Track różni się od ścieżek Closed i Open szybkością dostępu, wymaganiami dotyczącymi weryfikacji i skalą odbiorców. Internal nie wymaga moderacji, Closed wymaga konfiguracji Google Groups i weryfikacji, Open przechodzi pełną weryfikację Google.

Ścieżka Internal jest jedyną, gdzie kompilacja jest dostępna bez oczekiwania. Closed i Open wymagają weryfikacji Google, która zajmuje od kilku godzin do 2 dni. Dla nowych kont deweloperskich Open Testing Track jest obowiązkowy: aplikacja musi przejść 14-dniowe otwarte testowanie przed publikacją w produkcji.

Automatyzacja Internal Testing przez CI/CD

Automatyzacja przesyłania do Internal Testing Track to standardowa praktyka dla pipelineów CI/CD projektów Android. Gradle Play Publisher to najpopularniejszy plugin do automatycznej publikacji kompilacji. Podpisuje AAB, przesyła do Google Play i przypisuje ścieżkę.

Fastlane udostępnia akcję supply do przesyłania kompilacji do Play Console. Parametr track wskazuje docelową ścieżkę: internal, closedalpha, openbeta lub production. Zarządzanie wersjami i service account konfiguruje się raz w Fastfile.

# Fastfile - automatyczne przesyłanie do 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

Service account Google Play tworzy się w Google Cloud Console z rolą Publisher i przypisuje do konta deweloperskiego w Play Console. JSON-klucz service account jest przechowywany w repozytorium CI/CD jako chroniona zmienna (GitHub Secrets, GitLab CI Variables, Jenkins Credentials).