Internal Testing Track in Google Play: configurazione del track

Cos'è Internal Testing Track?

Internal Testing Track è il primo livello di test in Google Play Console, progettato per distribuire build all'interno del team di sviluppo. L'obiettivo principale è eseguire rapidi controlli di funzionalità, testare le integrazioni e identificare bug critici prima di espandere il pubblico ai track Closed o Open.

A differenza di altri track di Google Play, Internal Testing non richiede la revisione di Google prima dell'attivazione. Il build diventa disponibile per i tester in pochi minuti dopo il caricamento nella console. Ciò rende il track ideale per i build giornalieri (daily builds) e la consegna automatica dal pipeline CI/CD.

Secondo la documentazione di Google Play Console (2024), Internal Testing Track supporta due opzioni di distribuzione: elenco email (fino a 100 partecipanti) e Google Groups (senza limite di quantità). I gruppi sono adatti per team grandi dove i membri cambiano frequentemente, mentre l'email funziona meglio per un insieme fisso di sviluppatori.

Quando scegliere Internal Testing Track

Il track Internal viene scelto nelle fasi iniziali dello sviluppo, quando l'app è ancora instabile e le API possono cambiare. Un pipeline CI/CD carica ogni nuovo build nel track Internal e il team riceve immediatamente l'ultima versione. Gli errori e i log di crash vengono raccolti tramite Play Console prima che il build raggiunga tester o utenti esterni.

Per i nuovi account sviluppatore, Internal Testing Track funge da primo passo nella preparazione alla pubblicazione. Google non revisiona i build in questa fase, consentendo al team di verificare autonomamente la qualità del prodotto prima di inviarlo per la revisione.

Come configurare Internal Testing Track in Google Play Console

La configurazione di Internal Testing Track viene eseguita in Google Play Console nella sezione Release > Testing > Internal Testing. Il processo include la creazione del track, il caricamento del primo build e l'aggiunta dei tester.

Per creare il track, vai alla sezione Internal Testing e clicca su Create track. Dopo aver creato il track, il sistema ti chiederà di caricare il primo build in formato AAB (Android App Bundle). Google raccomanda AAB per tutti i tipi di test, poiché il formato ottimizza le dimensioni dell'app in base all'architettura del dispositivo.

Dopo il caricamento del build, l'accesso al track viene aperto aggiungendo tester. Senza almeno un tester, il track non è considerato attivo. Google Play Console mostra lo stato del track, l'elenco dei build caricati e le statistiche di installazione per ogni partecipante.

// build.gradle - caricamento automatico in Internal Testing Track
android {
    def versionCode = System.env.GIT_COMMIT_COUNT ?: "1"
    def versionName = "1.0." + versionCode

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

// Distribuzione tramite plugin Gradle Play Publisher
plugins {
    id 'com.github.triplet.play' version '3.9.0'
}

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

Aggiungere tester al track Internal

L'aggiunta di tester a Internal Testing Track è possibile in due modi: via email e tramite Google Groups. L'elenco email è adatto per team piccoli con composizione fissa. Ogni tester viene aggiunto manualmente nella console e riceve un invito all'indirizzo specificato.

Google Groups è preferibile per team con composizione variabile o gestione degli accessi automatizzata. Basta aggiungere il gruppo al track e tutti i suoi membri ottengono l'accesso ai build. La modifica della composizione del gruppo avviene senza aggiornare le impostazioni in Play Console.

I tester installano l'app tramite Google Play sul loro dispositivo. Dopo essere stati aggiunti al track, vedono l'app come disponibile per l'aggiornamento (se l'hanno installata precedentemente da un altro track) o come una nuova app da installare. I build del track Internal non vengono pubblicati pubblicamente — solo i partecipanti al track possono vederli.

Raccolta delle metriche nel track Internal

Google Play raccoglie automaticamente Android Vitals per tutti i build in Internal Testing Track: tasso di crash, ANR e tempo di avvio. Lo sviluppatore vede le metriche in Play Console immediatamente dopo che il primo tester installa il build. I dati sono disponibili in tempo reale senza ritardi di aggregazione.

Differenze tra Internal Testing e i track Closed e Open

Internal Testing Track si differenzia dai track Closed e Open per velocità di accesso, requisiti di revisione e scala del pubblico. Internal non richiede moderazione, Closed richiede la configurazione di Google Groups e la revisione, Open passa attraverso una revisione completa di Google.

Il track Internal è l'unico in cui il build è disponibile senza attesa. Closed e Open richiedono la revisione di Google, che richiede da alcune ore a 2 giorni. Per i nuovi account sviluppatore, Open Testing Track è obbligatorio: l'app deve superare 14 giorni di test aperti prima della pubblicazione in produzione.

Automazione di Internal Testing tramite CI/CD

L'automazione del caricamento in Internal Testing Track è una pratica standard per i pipeline CI/CD dei progetti Android. Gradle Play Publisher è il plugin più popolare per la pubblicazione automatica dei build. Firma l'AAB, lo carica su Google Play e assegna il track.

Fastlane fornisce l'azione supply per caricare i build in Play Console. Il parametro track specifica il track di destinazione: internal, closedalpha, openbeta o production. La gestione delle versioni e l'account di servizio vengono configurati una volta nel Fastfile.

# Fastfile - caricamento automatizzato in 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

Un account di servizio Google Play viene creato in Google Cloud Console con il ruolo Publisher e collegato all'account sviluppatore in Play Console. La chiave JSON dell'account di servizio viene archiviata nel repository CI/CD come variabile protetta (GitHub Secrets, GitLab CI Variables, Jenkins Credentials).