Migrer de Firebase Test Lab vers la plate-forme Developer Device

Nous avons le plaisir de vous annoncer la Preview de l'interface de ligne de commande gcloud beta device-run dans Developer Device Platform (DDP), une amélioration de l'interface CLI gcloud firebase test.

La CLI gcloud beta device-run simplifie et modernise l'exécution de tests d'automatisation et d'instrumentation sur l'appareil, qu'il soit physique ou virtuel. Dans la version Preview, Android Instrumentation et iOS XCTest sont compatibles. Pour obtenir des instructions, consultez la section Présentation de l'exécution sur l'appareil.

Présentation et avantages

Passer de Firebase Test Lab à la plate-forme Developer Device Platform (DDP) offre plusieurs avantages majeurs, en particulier en termes d'économies, de vitesse d'exécution des tests, de débogage avancé et de compatibilité intégrée avec les workflows basés sur l'IA.

Les développeurs qui exécutent des tests mobiles dans le cloud doivent jongler entre différents modèles de configuration (Firebase Test Lab) ou gérer des pipelines et des couches d'encapsulation d'outils supplémentaires (Flank).

La CLI gcloud beta device-run de la plate-forme Developer Device fusionne ces fonctionnalités directement dans la Google Cloud CLI principale. Il fournit une interface backend plus robuste, déclarative et évolutive qui exécute les tests de manière prévisible et efficace sur les appareils physiques et virtuels.

Voici les principales fonctionnalités et capacités qui font de DDP une plate-forme supérieure à Firebase Test Lab :

Advanced Smart Sharding

Alors que Firebase Test Lab s'appuie sur des données de timing à exécution unique pour partitionner les tests, le partitionnement intelligent de DDP est beaucoup plus intelligent :

  • Données historiques sur 30 jours : DDP analyse jusqu'à 30 jours d'historique d'exécution pour distribuer les tests dans des shards stables et optimisés.
  • Suivi de la durée spécifique à l'appareil : DDP suit les durées d'exécution des tests par modèle d'appareil spécifique plutôt que d'utiliser des moyennes de plate-forme généralisées pour tous les appareils.
  • Modélisation de la surcharge de l'orchestrateur : DDP tient compte de la surcharge de démarrage d'Android Test Orchestrator pour chaque instance de test, ce qui garantit que les fragments ne dépassent pas leurs durées cibles.

Réessayer de manière précise et économique

Dans Test Lab, si un cas de test unique d'un shard échoue, l'ensemble du shard (qui peut contenir des dizaines de tests) doit être relancé, ce qui augmente les temps d'exécution et les coûts de facturation. DDP introduit des mécanismes de nouvelle tentative très efficaces :

  • Nouvelles tentatives ciblées au niveau des scénarios de test : isole et relance uniquement les scénarios de test spécifiques en échec dans un shard.
  • Nouvelles tentatives séquentielles pour les tests instables : exécute les nouvelles tentatives pour les tests instables de manière séquentielle par défaut (au lieu de manière simultanée comme Test Lab). En combinant cela avec les nouvelles tentatives au niveau des scénarios de test, vous réduisez considérablement le nombre total d'exécutions de tests, ce qui permet de réaliser des économies importantes sur les coûts de facturation des appareils.

Assistance avancée pour les tests Android

DDP corrige les limites de longue date de l'API de test Test Lab :

  • APK de test uniquement (aucune application factice) : historiquement, Test Lab nécessitait une application factice pour exécuter des tests d'auto-instrumentation. DDP permet d'exécuter des tests d'instrumentation avec un seul APK de test.
  • Délai avant expiration étendu pour les fragments : DDP augmente la limite d'exécution maximale pour un seul fragment de test d'instrumentation, qui passe de 45 minutes (limite de Test Lab) à 3 heures.
  • Plusieurs orchestrateurs : DDP est compatible avec plusieurs versions d'Android Test Orchestrator.
  • Prise en charge des binaires C++ intégrés : DDP permet d'exécuter des binaires C++ Android.

Interactions enrichies avec les appareils et débogage avancé

DDP offre des interactions plus approfondies sur l'appareil et des artefacts de débogage beaucoup plus riches que ceux disponibles dans Test Lab :

  • Positions fictives : DDP permet de simuler les coordonnées GPS de l'appareil.
  • Compatibilité avec les ensembles d'APK : les développeurs peuvent installer des ensembles d'APK (fichiers .apks) directement sur les appareils à distance.
  • Débogage avancé : DDP expose directement au développeur les journaux système et les informations de débogage essentiels, y compris dumpsys et bugreport.

Catalogue d'appareils hautement évolutif

DDP remplace le catalogue d'environnements rigides et lourds de Test Lab par une API Device Catalog entièrement repensée :

  • Filtrage côté serveur : accélère les requêtes et réduit la latence de la charge utile en permettant aux développeurs de filtrer les appareils côté serveur.
  • Données de disponibilité en temps réel : DDP fournit des informations sur la disponibilité des appareils en temps réel directement à Device Run. Vous pouvez ainsi choisir des appareils disponibilité élevée et éviter les longues files d'attente, une fonctionnalité qui manque complètement à Test Lab.

Choisir votre chemin de migration

Automatiser votre migration avec l'IA

Pour faciliter cette transition, nous avons développé une compétence d'agent de traduction dédiée : migrating-device-run.

Si vous utilisez des agents de codage IA, tels qu'Antigravity, Claude Code ou Codex, vous pouvez facilement traduire vos scripts de test personnalisés. Il vous suffit de copier l'URL du schéma de la skill de migration et de la coller dans l'espace de travail de votre assistant IA, comme décrit ici.

Modèle de prompt de migration

You are an expert migration assistant. I want to migrate my test command and
configuration to the new `gcloud beta device-run` command format.

Use this migration guideline as your ruleset:
https://docs.cloud.google.com/developer-device-platform/device-run/migrate/migration-skill

Translate the following command and configuration to the new `gcloud beta
device-run` CLI: (Insert your raw Firebase Test / Flank YAML or bash script
here.)

Migrer manuellement

Suivez nos traductions de commandes et d'indicateurs pour migrer manuellement de Firebase Test Lab vers DDP. Lorsque vous vous préparez à migrer, gardez à l'esprit les différences structurelles suivantes :

  • Architecture CLI axée sur les ressources : gcloud beta device-run adopte un modèle de commande <resource> <verb> moderne dans trois principaux groupes de ressources :
    • devices : accès CLI direct à l'inventaire du catalogue d'appareils et informations détaillées sur les appareils, en remplacement des anciennes commandes firebase test android/ios models/versions/locales fragmentées.
    • software-versions : accès CLI direct aux versions logicielles compatibles (telles que les versions Xcode et Android Test Orchestrator), en remplacement de l'ancienne firebase test ios xcode-versions list.
    • sessions : gestion du cycle de vie des sessions de bout en bout directement dans le terminal, y compris sessions submit instrumentation, sessions submit xctest, sessions wait, sessions describe [--full], sessions list et sessions cancel.
  • Structure des sous-commandes : les types de tests sont standardisés et imbriqués sous sessions submit en tant que sous-commandes claires, au lieu d'utiliser des indicateurs de type.
    • DDP : gcloud beta device-run sessions submit instrumentation (Android) ou gcloud beta device-run sessions submit xctest (iOS)
    • Test Lab : gcloud firebase test android run --type=instrumentation (Android) ou gcloud firebase test ios run --type=xctest (iOS)
  • Applications fusionnées et au pluriel : les APK standards et supplémentaires sont fusionnées sous la liste des indicateurs --apps au pluriel (par exemple, --apps=app.apk,helper.apk) au lieu d'être divisé en --app et --additional-apks.
  • Arguments de dictionnaire et de liste structurés : les listes de fichiers ou d'environnement séparées par une virgule ont été remplacées par des formats de dictionnaire et de liste CLI structurés : --other-files-to-push KEY=VALUE, --additional-test-options KEY=VALUE, --paths-to-pull et --test-targets.
  • Contrôles unifiés du partitionnement et des nouvelles tentatives : compatibilité fluide avec le partitionnement uniforme et le partitionnement intelligent, ainsi qu'avec les nouvelles tentatives parallèles (--flaky-test-parallel-retry, --flaky-test-retry-level) et les diagnostics d'exécution (--dumpsys, --bugreport, --video).
  • Exécution asynchrone : gcloud beta device-run est compatible avec l'exécution asynchrone, ce qui vous permet d'exécuter des tests sans attendre qu'ils soient terminés. Utilisez gcloud beta device-run sessions wait <SESSION_ID> pour attendre la fin de l'opération.
  • Configuration YAML déclarative (--flags-file) : les équipes qui migrent depuis Flank et qui préfèrent les fichiers YAML contrôlés par version aux chaînes de script shell peuvent utiliser la compatibilité universelle --flags-file=device-run-flags.yaml de gcloud.

Étapes suivantes

  1. Utilisez notre guide de démarrage rapide pour configurer la plate-forme d'appareils pour les développeurs.
  2. Consultez notre catalogue d'appareils pour découvrir tous les appareils disponibles.
  3. Découvrez Device Run pour commencer à exécuter des tests.
  4. Consultez nos traductions de commandes et d'indicateurs pour voir un mappage des indicateurs Test Lab et Flank vers DDP.