Internal Testing Track dans Google Play : configuration du track

Qu’est-ce que l’Internal Testing Track ?

Internal Testing Track est le premier niveau de test dans Google Play Console, conçu pour distribuer des builds au sein de l’équipe de développement. L’objectif principal est de vérifier rapidement le fonctionnement, tester les intégrations et identifier les bugs critiques avant d’élargir l’audience aux tracks Closed ou Open.

Contrairement aux autres tracks Google Play, Internal Testing ne nécessite pas de validation Google avant l’activation. Le build est disponible pour les testeurs en quelques minutes après le téléchargement dans la console. Cela rend le track idéal pour les builds quotidiens (daily builds) et la livraison automatique depuis le pipeline CI/CD.

Selon la documentation de Google Play Console (2024), l’Internal Testing Track prend en charge deux options de distribution : liste d’e-mails (jusqu’à 100 participants) et Google Groups (sans limite de quantité). Les groupes conviennent aux grandes équipes dont les membres changent fréquemment, tandis que l’e-mail est plus adapté pour un ensemble fixe de développeurs.

Quand choisir l’Internal Testing Track

Le track Internal est choisi dans les premières phases de développement, lorsque l’application est encore instable et que les API peuvent changer. Un pipeline CI/CD télécharge chaque nouveau build dans le track Internal, et l’équipe reçoit la dernière version immédiatement. Les erreurs et les logs de crash sont collectés via Play Console avant que le build n’atteigne les testeurs ou utilisateurs externes.

Pour les nouveaux comptes développeur, l’Internal Testing Track sert de première étape de préparation à la publication. Google ne valide pas les builds à ce stade, ce qui permet à l’équipe de vérifier elle-même la qualité du produit avant de le soumettre à la validation.

Comment configurer l’Internal Testing Track dans Google Play Console

La configuration de l’Internal Testing Track se fait dans Google Play Console dans la section Release > Testing > Internal Testing. Le processus comprend la création du track, le téléchargement du premier build et l’ajout des testeurs.

Pour créer le track, allez dans la section Internal Testing et cliquez sur Create track. Après la création du track, le système vous invite à télécharger le premier build au format AAB (Android App Bundle). Google recommande l’AAB pour tous les types de test, car ce format optimise la taille de l’application en fonction de l’architecture de l’appareil.

Après le téléchargement du build, l’accès au track est ouvert en ajoutant des testeurs. Sans au moins un testeur, le track n’est pas considéré comme actif. Google Play Console affiche le statut du track, la liste des builds téléchargés et les statistiques d’installation pour chaque participant.

// build.gradle - Téléchargement automatique vers l’Internal Testing Track
android {
    def versionCode = System.env.GIT_COMMIT_COUNT ?: "1"
    def versionName = "1.0." + versionCode

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

// Déploiement via le plugin Gradle Play Publisher
plugins {
    id 'com.github.triplet.play' version '3.9.0'
}

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

Ajouter des testeurs au track Internal

L’ajout de testeurs à l’Internal Testing Track est possible de deux manières : par e-mail et via Google Groups. La liste d’e-mails convient aux petites équipes avec une composition fixe. Chaque testeur est ajouté manuellement dans la console et reçoit une invitation à l’adresse indiquée.

Google Groups est préférable pour les équipes avec une composition variable ou une gestion d’accès automatisée. Il suffit d’ajouter le groupe au track, et tous ses membres obtiennent l’accès aux builds. Le changement de composition du groupe se fait sans mettre à jour les paramètres dans Play Console.

Les testeurs installent l’application via Google Play sur leur appareil. Après avoir été ajoutés au track, ils voient l’application comme disponible pour mise à jour (s’ils l’ont installée précédemment depuis un autre track) ou comme une nouvelle application à installer. Les builds du track Internal ne sont pas publiés publiquement — seuls les participants au track peuvent les voir.

Collecte des métriques dans le track Internal

Google Play collecte automatiquement les Android Vitals pour tous les builds dans l’Internal Testing Track : taux de crash, ANR et temps de démarrage. Le développeur voit les métriques dans Play Console immédiatement après que le premier testeur installe le build. Les données sont disponibles en temps réel sans délai d’agrégation.

Différences entre Internal Testing et les tracks Closed et Open

Internal Testing Track diffère des tracks Closed et Open par la vitesse d’accès, les exigences de validation et l’échelle de l’audience. Internal ne nécessite pas de modération, Closed nécessite la configuration de Google Groups et une validation, Open passe par une validation complète de Google.

Le track Internal est le seul où le build est disponible sans attente. Closed et Open nécessitent une validation Google qui prend de plusieurs heures à 2 jours. Pour les nouveaux comptes développeur, l’Open Testing Track est obligatoire : l’application doit passer 14 jours de test ouvert avant la publication en production.

Automatisation de l’Internal Testing via CI/CD

L’automatisation du téléchargement vers l’Internal Testing Track est une pratique standard pour les pipelines CI/CD des projets Android. Gradle Play Publisher est le plugin le plus populaire pour la publication automatique des builds. Il signe l’AAB, le télécharge dans Google Play et attribue le track.

Fastlane fournit l’action supply pour télécharger les builds dans Play Console. Le paramètre track spécifie le track cible : internal, closedalpha, openbeta ou production. La gestion des versions et le compte de service sont configurés une fois dans le Fastfile.

# Fastfile - Téléchargement automatisé vers l’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 compte de service Google Play est créé dans Google Cloud Console avec le rôle Publisher et lié au compte développeur dans Play Console. La clé JSON du compte de service est stockée dans le référentiel CI/CD comme variable protégée (GitHub Secrets, GitLab CI Variables, Jenkins Credentials).