Internal Testing Track în Google Play: esență și configurare

Ce este Internal Testing Track?

Internal Testing Track — primul nivel de testare din Google Play Console, destinat distribuirii build-urilor în cadrul echipei de dezvoltare. Scopul principal este verificarea rapidă a funcționalității, testarea integrărilor și depistarea erorilor critice înainte de extinderea audienței la track-urile Closed sau Open.

Spre deosebire de alte track-uri Google Play, Internal Testing nu necesită verificare Google înainte de activare. Build-ul devine disponibil testerilor în câteva minute după încărcarea în consolă. Acest lucru face track-ul ideal pentru build-uri zilnice (daily builds) și livrare automată din pipeline-ul CI/CD.

Conform documentației Google Play Console (2024), Internal Testing Track suportă două variante de distribuire: listă de e-mail (până la 100 de participanți) și Google Groups (fără limită de număr). Grupurile sunt potrivite pentru echipe mari, unde participanții se schimbă mai des, iar e-mailul — pentru un grup fix de dezvoltatori.

Când să alegi Internal Testing Track

Track-ul Internal se alege în etapele timpurii de dezvoltare, când aplicația este încă instabilă, iar API-urile se pot schimba. Pipeline-ul CI/CD încarcă fiecare build nou în track-ul Internal, iar echipa primește versiunea proaspătă imediat. Erorile și log-urile de crash sunt colectate prin Play Console înainte ca build-ul să ajungă la testerii externi sau utilizatori.

Pentru conturile noi de dezvoltator, Internal Testing Track servește ca primă etapă de pregătire pentru publicare. Google nu verifică build-urile în această etapă, permițând echipei să se asigure singură de calitatea produsului înainte de a-l trimite la revizuire.

Cum să configurezi Internal Testing Track în Google Play Console

Configurarea Internal Testing Track se realizează în Google Play Console în secțiunea Release > Testing > Internal Testing. Procesul include crearea track-ului, încărcarea primei build-uri și adăugarea testerilor.

Pentru a crea track-ul, accesați secțiunea Internal Testing și faceți clic pe Create track. După crearea track-ului, sistemul va propune încărcarea primei build-uri în format AAB (Android App Bundle). Google recomandă AAB pentru toate tipurile de testare, deoarece formatul optimizează dimensiunea aplicației pentru arhitectura dispozitivului.

După încărcarea build-ului, accesul la track se deschide prin adăugarea testerilor. Fără cel puțin un tester, track-ul nu este considerat activ. Google Play Console afișează statusul track-ului, lista build-urilor încărcate și statistici de instalare pentru fiecare participant.

// build.gradle - încărcare automată în Internal Testing Track
android {
    def versionCode = System.env.GIT_COMMIT_COUNT ?: "1"
    def versionName = "1.0." + versionCode

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

// Implementare prin pluginul Gradle Play Publisher
plugins {
    id 'com.github.triplet.play' version '3.9.0'
}

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

Adăugarea testerilor în track-ul Internal

Adăugarea testerilor în Internal Testing Track este posibilă în două moduri: prin e-mail și prin Google Groups. Lista de e-mail este potrivită pentru echipe mici cu componență fixă. Fiecare tester este adăugat manual în consolă și primește o invitație pe adresa indicată.

Google Groups sunt preferabile pentru echipe cu componență variabilă sau gestionare automatizată a accesului. Este suficient să adăugați grupul în track și toți membrii săi obțin acces la build-uri. Modificarea componenței grupului se face fără actualizarea setărilor din Play Console.

Testerii instalează aplicația prin Google Play pe dispozitiv. După adăugarea în track, ei văd aplicația ca fiind disponibilă pentru actualizare (dacă au instalat-o anterior dintr-un alt track) sau ca o aplicație nouă de instalat. Build-urile din track-ul Internal nu sunt publicate public — le văd doar participanții track-ului.

Colectarea metricilor în track-ul Internal

Google Play colectează automat Android Vitals pentru toate build-urile din Internal Testing Track: frecvența crash-urilor, ANR și viteza de pornire. Dezvoltatorul vede metricile în Play Console imediat după instalarea build-ului de către primul tester. Datele sunt disponibile în timp real, fără întârzieri de agregare.

Diferențele dintre Internal Testing și track-urile Closed și Open

Internal Testing Track se deosebește de track-urile Closed și Open prin viteza de acces, cerințele de verificare și amploarea audienței. Internal nu necesită moderare, Closed necesită configurare Google Groups și verificare, iar Open trece prin verificarea completă Google.

Track-ul Internal este singurul unde build-ul este disponibil fără așteptare. Closed și Open necesită verificare Google, care durează de la câteva ore până la 2 zile. Pentru conturile noi de dezvoltator, Open Testing Track este obligatoriu: aplicația trebuie să treacă printr-o testare deschisă de 14 zile înainte de publicarea în producție.

Automatizarea Internal Testing prin CI/CD

Automatizarea încărcării în Internal Testing Track este o practică standard pentru pipeline-urile CI/CD ale proiectelor Android. Gradle Play Publisher este cel mai popular plugin pentru publicarea automată a build-urilor. Semnează AAB, îl încarcă în Google Play și atribuie track-ul.

Fastlane oferă acțiunea supply pentru încărcarea build-urilor în Play Console. Parametrul track indică track-ul țintă: internal, closedalpha, openbeta sau production. Gestionarea versiunilor și service account se configurează o dată în Fastfile.

# Fastfile - încărcare automată în 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 se creează în Google Cloud Console cu rolul Publisher și se asociază cu contul de dezvoltator din Play Console. Cheia JSON a service account-ului se stochează în depozitul CI/CD ca variabilă protejată (GitHub Secrets, GitLab CI Variables, Jenkins Credentials).