Von Firebase Test Lab und Flank zur Developer Device Platform mit KI migrieren

Dieser Skill hilft beim Übersetzen von Legacy-Testlaufkonfigurationen und ‑Workflows (von Flank oder gcloud firebase test) in die moderne, ressourcenorientierte gcloud beta device-run-Befehlszeilenoberfläche (und gcloud alpha device-run zum Senden von iOS-XCTest-Sitzungen).

Zuordnung von Befehls- und Ressourcenstruktur

Die Device Run-Befehlszeile organisiert Befehle nach Ressource: devices, software-versions und sessions:

1. Gerätekatalog (devices)

  • Geräte auflisten:
    • Legacy: gcloud firebase test android/ios models list
    • Neu: gcloud beta device-run devices list [--filter="..."]
    • Beispiel: gcloud beta device-run devices list --filter="platform:android"
  • Gerät beschreiben:
    • Legacy: gcloud firebase test android/ios models describe {MODEL}
    • Neu: gcloud beta device-run devices describe {DEVICE}
    • Beispiel: gcloud beta device-run devices describe redfin-30
  • Gerätekapazitäten und Verfügbarkeit prüfen:
    • Legacy: gcloud firebase test android/ios list-device-capacities
    • Neu: Direkt in die Geräteressource eingebettet (availability.capacity und availability.available). Mit gcloud beta device-run devices describe {DEVICE} prüfen oder direkt mit gcloud beta device-run devices list --filter="availability.capacity=CAPACITY_HIGH" filtern.

2. Softwareversionen (software-versions)

  • Unterstützte Softwareversionen auflisten (Xcode und Android Test Orchestrator):
    • Legacy: gcloud firebase test ios xcode-versions list
    • Neu: gcloud beta device-run software-versions list
  • Softwareversion beschreiben:
    • Neu: gcloud beta device-run software-versions describe {SOFTWARE_VERSION}
    • Beispiel: gcloud beta device-run software-versions describe xcode-16-4

3. Automatisierungssitzungen (sessions)

  • Android-Instrumentierung einreichen:
    • Legacy: gcloud firebase test android run --type=instrumentation ...
    • Neu: gcloud beta device-run sessions submit instrumentation ...
  • iOS-XCTest einreichen:
    • Legacy: gcloud firebase test ios run --type=xctest ...
    • Neu: gcloud alpha device-run sessions submit xctest ...
  • Warten, bis die Sitzung abgeschlossen ist:
    • Legacy: Nur synchrone CLI-Blockierung
    • Neu: gcloud beta device-run sessions wait {SESSION}
  • Sitzung beschreiben / untersuchen:
    • Legacy: Web-Link in der Firebase Console / in den Cloud Tool-Ergebnissen ansehen
    • Neu: gcloud beta device-run sessions describe {SESSION} [--full]
  • Frühere Sitzungen auflisten:
    • Legacy: Matrixverlauf in der Webkonsole ansehen
    • Neu: gcloud beta device-run sessions list
  • Sitzung abbrechen:
    • Legacy: Nur Webkonsole (kein CLI-Befehl)
    • Neu: gcloud beta device-run sessions cancel {SESSION}

Referenztabellen für Flag-Mapping

In der folgenden Tabelle werden Parameter aus dem alten Firebase Test Lab und Flank ihren unterstützten Entsprechungen in gcloud beta device-run zugeordnet:

Testtyp Featuregruppe Legacy-Parameter (Firebase/Flank) Zielparameter (device-run) Format / Conversion-Logik
Allgemein (Android und iOS) Wichtige Parameter und Assets Flanke --project --project Standardmäßiges globales Google Cloud -Flag (--project=PROJECT_ID) oder aktive Google Cloud CLI-Konfiguration.
Allgemein (Android und iOS) Wichtige Parameter und Assets --client-details --labels Dictionary mit Schlüssel/Wert-Paaren.
Allgemein (Android und iOS) Gerätekonfiguration und ‑targeting --device model={M},version={V} --device={M}-{V} Ordnet das Kartenmodell und die Betriebssystemversion dem --device-ID-String zu. Akzeptiert eine durch Kommas getrennte Liste mehrerer Geräte in einem einzelnen Flag (z. B. --device=mediumphone-arm-32,shiba-36).
Gemeinsam (Android und iOS) Ausführungskontrolle und Instabilität --async --async Maps 1:1 Der Befehl bleibt standardmäßig synchron. Übergeben Sie diesen Parameter, um sofort zurückzukehren. Überwachen oder warten mit gcloud beta device-run sessions wait <SESSION_ID>.
Allgemein (Android und iOS) Ausführungskontrolle und Flakiness --num-flaky-test-attempts {R} --flaky-test-attempts {A} Ganzzahl Konvertieren Sie die Anzahl der Wiederholungsversuche $R$ in das Limit für die Gesamtzahl der Versuche: $A = R + 1$ (Standardwert ist 1).
Allgemein (Android und iOS) Ausführungskontrolle und Flakiness – --flaky-test-parallel-retry Boolean. Gibt an, ob fehlgeschlagene Tests parallel wiederholt werden sollen (Standardeinstellung: sequenziell).
Allgemein (Android und iOS) Ausführungskontrolle und Flakiness – --flaky-test-retry-level String. Wiederholungsversuch: shard oder test (Standard ist shard).
Allgemein (Android und iOS) Ausgabe und Speicherung --results-bucket --bucket-name Bucket, in den Testausgabe-Artefakte hochgeladen werden (Standardwert: gs://[PROJECT_ID]-devicerun).
Allgemein (Android und iOS) Ausgabe und Speicherung --results-dir Automatisch verwaltet Das Festlegen benutzerdefinierter Unterverzeichnisse wird nicht unterstützt. Alle Testartefakte werden automatisch unter automation/sessions/{session_id}/ im Bucket organisiert, der durch --bucket-name angegeben wird.
Allgemein (Android und iOS) Ausgabe und Speicherung --record-video --video Gültige Werte: always oder on-failure.
Gemeinsam (Android und iOS) Ausgabe und Speicherung --directories-to-pull --paths-to-pull Liste der Pfade, die nach dem Ausführen vom Gerät abgerufen werden sollen.
Allgemeine Android- Wichtige Parameter und Assets --app --apps Liste: Wenn mehrere Anwendungs-APKs/AABs angegeben werden, müssen sie alle an --apps übergeben werden.
Häufige Android- Wichtige Parameter und Assets --additional-apks --apps Liste: Führen Sie zusätzliche Listenwerte direkt in die Hauptliste --apps ein.
Allgemeine Android- Wichtige Parameter und Assets --obb-files --other-files-to-push Wörterbuch im Format SOURCE=DEST. OBB-Dateien direkt in den Gerätepfad (/sdcard/Android/obb/{package_name}/) übertragen.
Häufige Android- Wichtige Parameter und Assets --other-files --other-files-to-push Wörterbuch im Format SOURCE=DEST.
Häufige Android- Gerätekonfiguration und Targeting --device locale={L} --locale={L} Ordnet die Gerätesprache dem übergeordneten --locale-Flag zu (language-region, z. B. --locale=en-US) verwenden.
Allgemeine Android- Gerätekonfiguration und Targeting --device orientation={O} --orientation={O} Ordnet die Geräteausrichtung dem Flag --orientation auf oberster Ebene zu (portrait oder landscape).
Häufige Android- Gerätekonfiguration und Targeting – --coordinates Koordinaten für simulierte Standortdaten (latitude,longitude, z. B. 37.4220,-122.0841).
Häufige Android- Ausführungskontrolle und Flakiness --grant-permissions Automatisierte Standardaktion Automatisiert: Laufzeitberechtigungen werden standardmäßig automatisch gewährt (entspricht --grant-permissions=all).|
Allgemeine Android- Ausgabe und Speicherung – --dumpsys Erfassen Sie dumpsys vom Gerät (always oder on-failure).
Allgemeine Android- Ausgabe und Speicherung – --bugreport Erstelle einen Fehlerbericht auf dem Gerät (always oder on-failure).
Android-Instrumentierung Wichtige Parameter und Assets --type=instrumentation sessions submit instrumentation Die Unterbefehlsstruktur bestimmt den Testtyp anstelle eines --type-Flags.
Android-Instrumentierung Wichtige Parameter und Assets --test --test Pfad zur Binärdatei, die Instrumentierungstests enthält.
Android-Instrumentierung Ausführungskontrolle und Flakiness --timeout --instrumentation-timeout Dauer (z. B. 10m, 20s, 1h). Gültiger Bereich: 1m bis 3h (Standardwert: 5m).
Android-Instrumentierung Ausführungskontrolle und Instabilität --num-uniform-shards {N} --sharding-option=uniform
--uniform-sharding-count={N} 		Die Flag-Konfiguration aktiviert die einheitliche Sharding-Strategie (gültiger Anzahlbereich: 1–20 physisch, 1–200 virtuell).
Android-Instrumentierung Ausführungskontrolle und Flakiness Flanke --shard-time {S} --sharding-option=smart
--smart-sharding-target-duration={S} 		Aktiviert Smart Sharding mit der Zielausführungszeit (z. B. 2m, 10m, 1h). Gültiger Bereich: 2m bis 1h.
Android-Instrumentierung Ausführungskontrolle und Flakiness Flanke --smart-flank-gcs-path --smart-sharding-record-name={name}
--bucket-name={bucket} 		Name der Sharding-Datensatz-YAML-Datei (ohne Erweiterung) in --bucket-name unter automation/smart-sharding/.
Android-Instrumentierung Ausführungskontrolle und Flakiness Flanke --max-test-shards {N} --smart-sharding-max-shard-count={N} Wird einer maximalen Shard-Grenze zugeordnet, wenn Smart Sharding aktiviert ist (0–20 physisch, 0–200 virtuell).
Android-Instrumentierung Test-Runner und Ziele --test-runner-class --test-runner-class Vollständig qualifizierte Runner-Klasse.
Android-Instrumentierung Test-Runner und Ziele --test-targets --test-targets Wörterbuch mit Unterstützung für Schlüssel wie package, notPackage, class, notClass, annotation, notAnnotation und size. Formate wie testfile oder notTestfile werden nicht unterstützt.
Android-Instrumentierung Test-Runner und Ziele --use-orchestrator --orchestrator-version Akzeptiert auto (Standard-Orchestrator) oder einen bestimmten Versionsstring (z. B. 1.6).
Android-Instrumentierung Test-Runner und Ziele --environment-variables --additional-test-options Dictionary mit Optionen, die an den Test Runner übergeben werden. In --test-targets unterstützte Formate sind hier nicht zulässig.
Gängige iOS-Versionen Wichtige Parameter und Assets --additional-ipas --additional-apps Liste der .ipa-Dateien, die vor dem Testlauf auf dem Gerät installiert werden sollen.
Gängige iOS-Versionen Wichtige Parameter und Assets --other-files --other-files-to-push Wörterbuch im Format SOURCE=BUNDLE_ID:DEVICE_PATH.
Gängige iOS-Versionen Gerätekonfiguration und Targeting --device locale={L} --locale={L} Ordnet die Gerätesprache dem übergeordneten --locale-Flag zu (language-region, z. B. --locale=en-US) verwenden.
Gängige iOS-Geräte Ausgabe und Speicherung --directories-to-pull --paths-to-pull Liste der Dateien oder Verzeichnisse, die nach dem Test im Format BUNDLE_ID:DEVICE_PATH abgerufen werden sollen.
Nur iOS XCTest Wichtige Parameter und Assets --type=xctest sessions submit xctest Die Unterbefehlsstruktur bestimmt den Testtyp anstelle eines --type-Flags (verwendet gcloud alpha).
Nur iOS XCTest Wichtige Parameter und Assets --test --test Der Pfad zur ZIP-Datei, die die iOS-App und die XCTest-Dateien enthält.
Nur iOS XCTest Ausführungskontrolle und Flakiness --timeout --xctest-timeout Maximal zulässige Dauer für den XCTest-Lauf (gültiger Bereich: 1m bis 1h, Standardwert: 5m).
Nur iOS XCTest Test-Runner und Ziele --xctestrun-file --xctestrun-file Der Pfad zur benutzerdefinierten .xctestrun-Datei.
Nur iOS XCTest Test-Runner und Ziele --xcode-version --xcode-version Katalog-ID oder Versionsstring von Xcode, der verwendet werden soll (z. B. xcode-16-4 oder 16.4). Abfrage mit software-versions list.

Umsetzbare Übersetzungshinweise

Folgen Sie diesen Richtlinien, um Firebase Test Lab- und Flank-Konfigurationen in Device Run zu übersetzen:

1. Gerätespezifikationen

In gcloud beta device-run akzeptiert --device eine durch Kommas getrennte Liste von Modell- und Versions-ID-Strings. Im Gegensatz zu Firebase, wo ein --device-Flag pro Gerät erforderlich war, können Sie mit „device-run“ mehrere Geräte in einem Flag angeben. Gebietsschema, Ausrichtung und simulierte Koordinaten des Geräts werden mit separaten Flags auf oberster Ebene angegeben:

  • ❌ --device model=MediumPhone.arm,version=32,locale=en,orientation=portrait
  • ✅ --device=mediumphone-arm-32 --locale=en-US --orientation=portrait

2. Wörterbücher und Listen

Konvertieren Sie kommagetrennte Flags in Listen (--apps, --paths-to-pull) oder Schlüssel/Wert-Dictionaries (--other-files-to-push, --additional-test-options):

  • ❌ --other-files /sdcard/file1.txt=local/file1.txt,/sdcard/file2.txt=local/file2.txt
  • ✅ --other-files-to-push local/file1.txt=/sdcard/file1.txt,local/file2.txt=/sdcard/file2.txt

3. Fragmentierungsstrategien

  • Einheitliche Fragmentierung:
    • Legen Sie dazu --sharding-option=uniform fest.
    • Legen Sie --uniform-sharding-count={count} fest (1–20 für physische, 1–200 für virtuelle).
  • Smart Sharding:
    • Legen Sie dazu --sharding-option=smart fest.
    • Legen Sie --smart-sharding-target-duration={duration} fest (z. B. 2m, 10m, 1h; gültiger Bereich: 2m bis 1h).
    • Legen Sie --smart-sharding-record-name={record_name} fest (verweist auf den YAML-Tracking-Eintrag in --bucket-name unter automation/smart-sharding/).
    • Legen Sie --smart-sharding-max-shard-count={max_count} fest (optionales Maximum: 0–20 für physische Produkte, 0–200 für virtuelle Produkte).

4. Asynchrone Ausführung

  • Asynchron und wartend: Wenn --async angegeben ist, gibt die Befehlszeile sofort die erstellte Sitzungs-ID zurück. Sie können in CI/CD-Workflows mit folgenden Methoden auf den Abschluss einer Sitzung warten: gcloud beta device-run sessions wait <SESSION_ID>

5. Deklarative YAML-Konfiguration (--flags-file)

Für komplexe Konfigurationen oder Teams, die lieber versionsverwaltete Dateien als lange Terminalbefehle verwalten, bietet gcloud einen universellen --flags-file-Argumentpräprozessor (siehe $ gcloud topic flags-file):

gcloud beta device-run sessions submit instrumentation --flags-file=device-run-flags.yaml

!HINWEIS Warum Schlüssel -- erfordern: gcloud fügt YAML-Schlüssel direkt als Befehlszeilen-Flags in den CLI-Parser ein. Jedem Schlüssel in der YAML-Datei muss das Präfix -- vorangestellt werden (z. B. --device:, --apps:). Ohne -- lehnt gcloud sie als nicht erkannte Positionsargumente ab.

Hier ein Beispiel für Flags mit mehreren Werten für Listen und Wörterbücher:

# device-run-flags.yaml
--device:
  -   mediumphone-arm-32
  -   shiba-36
--apps:
  -   app-debug.apk
  -   test-helper.apk
--test: app-debug-androidTest.apk
--bucket-name: my-bucket
--sharding-option: smart
--smart-sharding-target-duration: 2m
--smart-sharding-record-name: timing-record
--paths-to-pull:
  -   /sdcard/screenshots
  -   /sdcard/coverage.ec
--additional-test-options:
  coverage: "true"
  clearPackageData: "true"

Beispielübersetzungen

Anhand dieser Beispiele können Sie Ihre vorhandenen Firebase Test Lab- und Flank-Konfigurationen in Device Run-Konfigurationen übersetzen.

Firebase Test Lab für Device Run

firebase cmd:

gcloud firebase test android run \
  --app=app-debug.apk \
  --test=app-debug-androidTest.apk \
  --device model=shiba,version=36 \
  --timeout=5m \
  --num-flaky-test-attempts=2 \
  --directories-to-pull=/sdcard/screenshots \
  --environment-variables coverage=true

Übersetzung:

gcloud beta device-run sessions submit instrumentation \
  --device=shiba-36 \
  --apps=app-debug.apk \
  --test=app-debug-androidTest.apk \
  --instrumentation-timeout=5m \
  --flaky-test-attempts=3 \
  --paths-to-pull=/sdcard/screenshots \
  --additional-test-options coverage=true

Flank-Konfigurationen für die Geräteausführung

flank options (flank.yml):

gcloud:
  app: app-debug.apk
  test: app-debug-androidTest.apk
  device:
    -   model: mediumphone-arm
      version: 32
  shard-time: 120
  smart-flank-gcs-path: gs://my-bucket/automation/smart-sharding/timing-record.yaml

Das bedeutet:

Übersetzen Sie direkt in den modernen CLI-Befehl:

gcloud beta device-run sessions submit instrumentation \
  --device=mediumphone-arm-32 \
  --apps=app-debug.apk \
  --test=app-debug-androidTest.apk \
  --bucket-name=my-bucket \
  --sharding-option=smart \
  --smart-sharding-target-duration=2m \
  --smart-sharding-record-name=timing-record

Option 2: Deklarative YAML-Flags-Datei (--flags-file)

Wenn Sie Konfigurationen lieber in einer versionsverwalteten YAML-Datei als in Shell-Skriptstrings verwalten möchten, verwenden Sie das integrierte --flags-file-Feature von gcloud:

# device-run-flags.yaml
# Note: gcloud requires keys to start with '--'
--device:
  -   mediumphone-arm-32
--apps:
  -   app-debug.apk
--test: app-debug-androidTest.apk
--bucket-name: my-bucket
--sharding-option: smart
--smart-sharding-target-duration: 2m
--smart-sharding-record-name: timing-record

Mit der Befehlszeile senden:

gcloud beta device-run sessions submit instrumentation --flags-file=device-run-flags.yaml

(Sie können Flags auch in der Befehlszeile anhängen oder überschreiben, z. B. --async hinzufügen).

Gerätekatalog-Erkennung

listing & inspecting devices:

# List all available Android devices
gcloud beta device-run devices list --filter="platform:android"

# Filter devices with high fleet capacity (replaces legacy list-device-capacities)
gcloud beta device-run devices list --filter="availability.capacity=CAPACITY_HIGH"

# Describe a specific device (OS versions, form factors, orientation, locales, capacity)
gcloud beta device-run devices describe redfin-30

End-to-End-Sitzungslebenszyklus in CI/CD

submitting, waiting, and inspecting sessions:

# 1. Submit asynchronously and capture session ID
SESSION_ID=$(gcloud beta device-run sessions submit instrumentation \
  --apps=app-debug.apk \
  --test=app-debug-androidTest.apk \
  --device=mediumphone-arm-32 \
  --async \
  --format="value(name)")

# 2. Wait for session completion in CI/CD pipeline
gcloud beta device-run sessions wait "$SESSION_ID"

# 3. Describe session summary (or pass --full for complete details)
gcloud beta device-run sessions describe "$SESSION_ID"

# 4. Cancel a running session if aborted
gcloud beta device-run sessions cancel "$SESSION_ID"