Google PCD: Testen, Qualitäts-Engineering und sicheres Release-Management — Lernleitfaden

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Teil des Google Professional Cloud Developer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Teams mit hoher Entwicklungsgeschwindigkeit auf Google Cloud kombinieren rigorose Tests mit progressiver Bereitstellung, um Risiken zu reduzieren und gleichzeitig Änderungen zu beschleunigen. Eine robuste Strategie umfasst Unit- bis hin zu End-to-End-Tests, realistische Daten- und Abhängigkeitssimulation, automatisierte Qualitätstore und kontrollierte Release-Muster wie Canary und Blue-Green. Observability, Eigenverantwortung und eine disziplinierte Verifizierung nach der Veröffentlichung schließen den Kreis. Dieser Abschnitt beschreibt, wie man mit Google Cloud-Diensten auf Zuverlässigkeit hin entwirft, Risiken isoliert und Builds sicher über verschiedene Umgebungen hinweg befördert.

Teststrategie und Datenmanagement

Testpyramide und Testtypen

Unit-Tests: Schnelle, isolierte Überprüfung von Funktionen, Klassen und kleinen Modulen. Diese sollten den größten Teil der Test-Suite ausmachen. Führen Sie sie bei jedem Commit und Pull Request aus.
Integrationstests: Validieren die Interaktionen zwischen Komponenten, wie z. B. der Anwendung und ihrem Datenspeicher oder ihrer Warteschlange. Verwenden Sie Google Cloud-Emulatoren, wo immer diese verfügbar sind.
Contract-Tests: Consumer-Driven Contracts für Microservices verhindern Breaking Changes an APIs. Validieren Sie das Verhalten des Providers anhand des vom Consumer erwarteten Schemas und der Semantik vor der Integration. Verwenden Sie Pact oder ähnliche Tools; versionieren Sie Ihre API und veröffentlichen Sie Schemas.
End-to-End-Tests: Trainieren den gesamten Systempfad unter Verwendung von produktionsähnlicher Konfiguration, Identität und Netzwerkrichtlinien. Begrenzen Sie ihre Anzahl, parallelisieren Sie sie und führen Sie sie in Pre-Prod-Umgebungen aus.
Smoke-Tests: Minimale Prüfungen, die bestätigen, dass kritische Abhängigkeiten, Routen und Health Checks nach jedem Deployment korrekt funktionieren. Dies ist Ihre erste Verifizierung nach dem Deployment.

Testdatenmanagement, Isolation, Reproduzierbarkeit und Umgebungsparität

Data Seeding: Generieren Sie kleine, deterministische Datensätze für Unit-Tests und größere, repräsentative Datensätze für Integrations-/Performancetests. Befüllen Sie die Daten aus Fixtures, die in die Quellcodeverwaltung eingecheckt sind.
Isolation: Stellen Sie sicher, dass Tests keinen gemeinsamen Zustand haben. Verwenden Sie ephemere Datenbanken, isolierte GKE-Namespaces und eindeutige Präfixe für Cloud Storage-Objekte. Erstellen Sie für SQL pro Test ein eigenes Schema; für Pub/Sub generieren Sie temporäre Topics/Subscriptions.
Reproduzierbarkeit: Pinnen Sie Abhängigkeitsversionen, machen Sie Builds hermetisch und fixieren Sie Zufalls-Seeds. Speichern Sie Test-Container mit Digests in Artifact Registry.
Umgebungsparität: Standardisieren Sie Container-Images und Infrastructure-as-Code über Entwicklung, QA, Staging und Produktion hinweg. Halten Sie die Konfiguration aus den Images heraus und verwenden Sie umgebungsspezifische Metadaten und Secrets. Speichern Sie für Compute Engine Werte pro Deployment in den Metadaten der Instanzvorlage; für projektübergreifende Parität konfigurieren Sie einen Umgebungsschlüssel in den Metadaten und lesen Sie ihn beim Start aus, um die umgebungsspezifische Konfiguration auszuwählen.

Mocking, Emulatoren, Fakes und Sandbox-Dienste

Mocks/Stubs: Ersetzen Sie Kollaborateure auf Unit-Ebene, um Logik zu isolieren und Netzwerkaufrufe zu vermeiden. Vermeiden Sie übermäßiges Mocking; prüfen Sie das Verhalten, nicht die Implementierungsdetails.
Emulatoren: Bevorzugen Sie offizielle Emulatoren für Integrationstests. Beispiele: Firestore/Datastore, Pub/Sub, Spanner und Bigtable Emulatoren. Sie bieten API-Treue ohne Cloud-Kosten und beschleunigen die CI.
Fakes: Wenn kein Emulator existiert, führen Sie leichtgewichtige lokale Fakes (z. B. einen Fake Object Store) oder gemeinsam genutzte Sandbox-Dienste mit starker Isolation und Quotas aus.
Simulation externer Abhängigkeiten: Führen Sie für APIs von Drittanbietern vertragsbasierte Fakes hinter einem Service Mesh oder API-Gateway aus; konfigurieren Sie Timeouts, Retries und Chaos Injection, um die Fehlerbehandlung zu testen.

Häufige Fehlermodi und Kompromisse

Ein übermäßiges Verlassen auf End-to-End-Tests verlangsamt die Iteration; investieren Sie in Unit- und Contract-Tests, um Probleme früher zu erkennen.
Gemeinsam genutzte, langlebige Testumgebungen akkumulieren Drift und Datenverschmutzung. Bevorzugen Sie ephemere Umgebungen und ein idempotentes Setup/Teardown.
Emulatoren spiegeln die Produktion möglicherweise nicht perfekt wider. Verwenden Sie gestagte E2E-Tests mit echten Diensten vor der Beförderung in die nächste Stufe.

Kurzes Cloud Build-Beispiel zur Trennung fehlschlagender Stufen

steps:
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'make compile && make unit']
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'docker build -t $IMAGE .']
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'make integration']  # run against emulators or ephemeral env
images: ['$IMAGE']

Getrennte Schritte stellen sicher, dass die Build-Historie genau anzeigt, ob die Kompilierung/Unit-Tests, der Build oder die Integration fehlgeschlagen sind.

Nicht-funktionale Tests und Code-Qualität

Performancetests

Typen: Last- (Steady-State), Stress- (über die Spitze hinaus), Soak- (Langzeit-) und Kapazitätstests.
Tooling: Verwenden Sie Cloud Monitoring für SLOs und Benachrichtigungen, Cloud Trace für die Latenz-Analyse und Cloud Profiler zur Identifizierung von Hot Paths. Für GKE skalieren Sie mit dem Cluster Autoscaler und HPA; für Pub/Sub-Worker handhabt HPA auf Basis externer Metriken die durch Spitzenlasten bedingte Skalierung.
Tests in der Produktion: Nutzen Sie Dark Launches und Request Mirroring, um neue Backends sicher mit Produktions-Traffic zu evaluieren. External HTTP(S) Load Balancing unterstützt Request Mirroring; Anthos Service Mesh unterstützt Traffic Shadowing.

Sicherheitstests

SAST/Secret-Scanning: Führen Sie statische Analysatoren in der CI aus und lehnen Sie hartcodierte Anmeldeinformationen ab. Speichern Sie Secrets im Secret Manager mit Zugriff nach dem Prinzip der geringsten Rechte.
Abhängigkeits- und Image-Scanning: Aktivieren Sie Container Analysis in Artifact Registry. Setzen Sie Richtlinien mit Binary Authorization durch, das vor dem Deployment Attestierungen verlangt, dass keine kritischen Schwachstellen vorhanden sind.
DAST: Scannen Sie Staging-Umgebungen mit authentifizierten Scannern und blockieren Sie Releases bei kritischen Befunden.

Barrierefreiheit und Regression

Barrierefreiheit: Integrieren Sie automatisierte a11y-Prüfungen (z. B. Lighthouse CI) in nicht-blockierende Pre-Merge-Prüfungen; beheben Sie Probleme vor dem Release.
Regressions-Suites: Pflegen Sie kuratierte, stabile Regressions-Suites für kritische Pfade. Führen Sie Smoke-Tests bei jedem Deployment und vollständige Regressionstests für Release-Kandidaten durch.

Statische Analyse, Qualitätstore und Code-Review

Statische Analyse: Konfigurieren Sie sprachspezifische Linter und Formatierer als Pre-Submit-Prüfungen. Verwenden Sie Bazel oder Ähnliches zur Parallelisierung.
Qualitätstore: Lassen Sie Builds bei Schwellenwertüberschreitungen (Abdeckung, Komplexität, Lint-Fehler) fehlschlagen. Veröffentlichen Sie die Ergebnisse in den Cloud Build-Logs.
Code-Review: Fordern Sie eine Zwei-Personen-Überprüfung für riskante Änderungen, CODEOWNERS für kritische Pfade und eine Presubmit-CI für Tags, die für Releases verwendet werden.
Supply Chain: Generieren Sie SBOMs, signieren Sie Artefakte und speichern Sie die Provenienz. Erzwingen Sie Attestierungsprüfungen in Binary Authorization.

Progressive Delivery und sichere Releases

Bereitstellungsstrategien

Rolling: Pods oder Instanzen schrittweise ersetzen. Geringes Risiko für zustandslose Dienste; mit Readiness Probes und Surge-/Verfügbarkeitseinstellungen kombinieren.
Blue/Green: Eine komplett neue Umgebung aufbauen, Verifizierung durchführen, dann den Traffic umschalten. Ermöglicht sofortiges Rollback durch Zurücksetzen des Load Balancers. Ideal, wenn ein sofortiger Fallback erforderlich ist.
Canary: Einen kleinen Prozentsatz des Traffics schrittweise auf die neue Version verlagern und dabei wichtige Metriken beobachten. Bei fehlerfreiem Zustand automatisch hochstufen; bei Regressionen zurückrollen.
Traffic-Splitting: Routing nach Prozentsatz oder Attributen (Header, Cookies, User-Agent) mit GKE plus Anthos Service Mesh oder Nutzung des integrierten Splittings in Cloud Run und App Engine.

Feature-Flags und Experimente

Feature-Flags: Bereitstellung vom Release entkoppeln. Flags für schrittweises Rollout, Kill-Switches und Experiment-Schalter verwenden. Zentral speichern (z. B. in einem verwalteten Flag-Dienst oder einem durch IAM geschützten Konfigurationsspeicher). Die Lebensdauer von Flags kurz halten und Altlasten entfernen.
Dark Launches: Features deaktiviert bereitstellen; Validierung durch interne Benutzer oder synthetischen Traffic.
Shadow Traffic: Produktionsanfragen auf neue Dienste spiegeln, ohne die Benutzer zu beeinträchtigen; Antworten vergleichen, um Regressionen zu erkennen.
Kontrollierte Experimente: A/B- oder multivariates Routing mit Service-Mesh-Regeln implementieren. Für User-Agent-basierte Experimente Routing nach Header-Übereinstimmung durchführen.

Gates, Genehmigungen, Rollback und Observability

Deployment-Gates: Pre-Deploy-Integrationstests und Post-Deploy-Smoke-/Health-Checks hinzufügen. Für die Höherstufung von Umgebungen tag-basierte Trigger verwenden, um Build vom Release zu trennen.
Manuelle Genehmigungen: Menschliche Genehmigung an Meilensteinen wie von Staging zu Produktion erforderlich machen. Cloud Deploy unterstützt manuelle Genehmigungsschritte pro Ziel (Target).
Automatisches Rollback: SLOs und Benachrichtigungsrichtlinien definieren; wenn ein Canary die Schwellenwerte für Fehlerrate oder Latenz verletzt, automatisch durch Aufrufen der Deploy-API zurückrollen. Rollbacks schnell und gut eingeübt halten.
Release-Observability: Releases mit Versions-Labels in Metriken und Logs instrumentieren. Prometheus-Metriken nach Cloud Monitoring exportieren und logbasierte Metriken für Fehlermuster erstellen, um Telemetriedaten kosteneffizient zu korrelieren.

Kurzes ASM-Routing-Beispiel für ein header-basiertes Canary-Release

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  http:
  - match:
    - headers:
        user-agent:
          regex: ".*Android.*"
    route:
    - destination: { host: svc, subset: v2 }  # canary
  - route:
    - destination: { host: svc, subset: v1 }  # stable

Testzuverlässigkeit, Feedback-Schleifen und Post-Release-Disziplin

Management und Zuverlässigkeit von unzuverlässigen (flaky) Tests

Erkennen und unter Quarantäne stellen: Verfolgen Sie die Unzuverlässigkeit von Tests im Zeitverlauf; stellen Sie bekannte unzuverlässige Tests unter Quarantäne und blockieren Sie Releases nicht aufgrund dieser, während Sie die Behebung priorisieren.
Timeouts und Wiederholungsversuche: Fügen Sie sinnvolle Timeouts hinzu; erlauben Sie einen einzelnen Wiederholungsversuch bei vermuteten Infrastruktur-Flakes, nicht bei Logikfehlern.
Hermetische Builds: Vermeiden Sie Netzwerkaufrufe in Unit-Tests; pinnen Sie Artefakte und verwenden Sie Emulatoren, um Nichtdeterminismus zu reduzieren.
Parallelisierung: Verteilen (sharden) Sie Tests in Cloud Build auf mehrere Schritte oder Worker, um die Latenz des Feedbacks zu minimieren.

Feedback-Schleifen

CI-Trigger: Führen Sie Unit- und Integrationstests bei jedem Commit zu main und bei Pull-Requests aus. Verwenden Sie separate Cloud Build-Schritte, damit die Build-Historie die fehlschlagende Phase identifiziert. Erstellen Sie Release-Trigger für Git-Tags, nicht für jeden Commit, um Deployments zu steuern.
Progressive Verifizierung: Führen Sie nach einem erfolgreichen Deployment eine automatische Beförderung (Promotion) von der Entwicklungs- (Dev) in die Testumgebung durch, indem Sie Cloud Deploy Pub/Sub-Benachrichtigungen abonnieren und die Promotion bei SUCCEEDED-Ereignissen aufrufen.
Metrikgesteuerte Promotion: Steuern Sie bei Canary-Deployments die Erhöhung des Traffics (Ramp-up) anhand von Cloud Monitoring-Metriken und SLOs.

Release-Dokumentation, Verantwortlichkeit und Post-Release-Verifizierung

Dokumentation: Pflegen Sie Release Notes, Runbooks und Rollback-Verfahren direkt neben dem Code. Verfolgen Sie Change-Tickets mit Links zu Commits, Images und Umgebungsversionen.
Verantwortlichkeit: Definieren Sie Rufbereitschaftsrotationen und Komponentenverantwortliche; erzwingen Sie CODEOWNERS für sensible Bereiche. Stellen Sie klare Genehmiger für Promotions in die Produktion sicher.
Post-Release-Verifizierung: Führen Sie Smoke-Test-Suites aus, stellen Sie sicher, dass die Fehlerbudgets intakt bleiben, und überprüfen Sie Dashboards nach Versions-Tag. Bestätigen Sie, dass Sicherheits- und Schwachstellenberichte innerhalb der Richtlinien bleiben. Wenn Probleme auftreten, führen Sie zuerst ein Rollback durch und beginnen Sie dann mit der Ursachenanalyse.

Praktisches Problemszenario

Das Plattformteam von Acme Retail standardisiert Tests und Releases für eine GKE-basierte Microservices-Anwendung, die auch ein zustandsloses Web-Frontend auf Cloud Run umfasst. Sie müssen schnelles Feedback sicherstellen, riskante Builds blockieren und neue Funktionen sicher ausrollen, während sie Live-Traffic zur Leistungsbewertung nutzen.

Ansatz

Trennen Sie Build- und Testphasen in Cloud Build

Begründung: Verwenden Sie separate Schritte zum Kompilieren, Ausführen von Unit-Tests, Erstellen des Containers und Ausführen von Integrationstests, damit die Build-Historie die fehlschlagende Phase genau anzeigt und Entwickler schnell umsetzbares Feedback erhalten.
Beispiel:

steps:
- name: gcr.io/cloud-builders/docker
  args: ['build', '-t', '$IMAGE', '.']
- name: gcr.io/cloud-builders/gcloud
  args: ['bash','-lc','make unit']
- name: gcr.io/cloud-builders/gcloud
  args: ['bash','-lc','make integration']  # against emulators
images: ['$IMAGE']

Führen Sie Integrationstests gegen Emulatoren und ephemere Namespaces aus

Begründung: Verwenden Sie für Pub/Sub-Worker und Firestore-gestützte Dienste die Pub/Sub- und Firestore-Emulatoren. Für Dienste, die Cluster-Richtlinien erfordern, erstellen Sie pro Build einen ephemeren GKE-Namespace mit temporären Topics und Service Accounts über Workload Identity. Dies bietet Isolation, Geschwindigkeit und niedrige Kosten bei gleichzeitiger Wahrung der Realitätsnähe.

Erzwingen Sie Sicherheits-Qualitätstore mit Artifact Registry und Binary Authorization

Begründung: Aktivieren Sie das Scannen nach Schwachstellen beim Push von Images, lassen Sie die Pipeline bei kritischen CVEs fehlschlagen und fordern Sie Attestierungen in Binary Authorization an, bevor Sie in GKE deployen. Dies verhindert die Bereitstellung von Images mit bekannten kritischen Schwachstellen.

Verwenden Sie Git-Tag-basierte Release-Trigger

Begründung: Cloud Build-Trigger auf Tags (z. B. vX.Y.Z) ermöglichen automatisierte Releases nur für explizit getaggte Commits und vermeiden so versehentliche Produktions-Deployments von jedem Commit zu main.

Progressive Bereitstellung mit Cloud Deploy und Anthos Service Mesh

Begründung: Definieren Sie eine Cloud Deploy-Pipeline mit Entwicklungs-, Test- und Produktionszielen (dev, test, prod). Verwenden Sie eine manuelle Genehmigung, um die Promotion in die Produktion zu steuern. Nutzen Sie für die Produktion eine Canary-Strategie mit ASM, um den Traffic schrittweise auf 5 %, 25 %, 50 %, 100 % zu verlagern, während die SLOs überwacht werden. Cloud Deploy abonniert Verifizierungs-Hooks; ein Fehler stoppt oder rollt das Canary-Deployment automatisch über die API zurück.

Observability und automatisierte Rollback-Hooks

Begründung: Exportieren Sie Prometheus-Metriken nach Cloud Monitoring und erstellen Sie logbasierte Metriken für Fehlersignaturen. Konfigurieren Sie Alert-Richtlinien für Metriken mit Versions-Label. Eine Cloud Function, die Alerts abonniert, ruft die Cloud Deploy API auf, um das Rollout anzuhalten oder zurückzurollen. Dies verbindet objektive Zustandssignale mit der Steuerung des Deployments.

Shadow Traffic und A/B-Validierung für das Cloud Run-Frontend

Begründung: Verwenden Sie Request Mirroring am externen HTTP(S) Load Balancer, um Produktionsanfragen an die neue Cloud Run-Revision zu leiten, ohne die Benutzer zu beeinträchtigen. Nutzen Sie anschließend die Traffic-Aufteilung von Cloud Run, um kleine Prozentsätze zu verschieben und Latenz-/Fehlermetriken vor der vollständigen Umstellung zu vergleichen.

Blue-Green-Fallback für kritische Backend-Dienste

Begründung: Für Dienste, die ein sofortiges Rollback erfordern, pflegen Sie Blue- und Green-Deployments hinter einem einzigen Backend-Dienst. Validieren Sie die Green-Umgebung mit Smoke- und Contract-Tests und schalten Sie dann den Traffic um. Bei Anomalien kann sofort zurückgeschaltet werden.

Post-Release-Verifizierung und Dokumentation

Begründung: Führen Sie nach der Promotion automatisierte Smoke-Tests aus, überprüfen Sie Dashboards nach Release-Version und aktualisieren Sie die Release Notes mit Artefakt-Digests und der Rollout-Historie. Die Verantwortlichkeit und die Rufbereitschaft übernehmen die Übergabe; wenn Fehlerbudgets aufgebraucht werden, führen Sie zuerst ein Rollback durch und anschließend eine schuldlose Analyse.

Dieser Ansatz liefert schnelles, zuverlässiges Feedback in der CI, erzwingt Sicherheit und Qualität und verwendet sichere, beobachtbare Rollout-Strategien, die sowohl attributbasierte Experimente als auch bei Bedarf ein sofortiges Rollback unterstützen.

← Performance · Alle Domänen · Kosten →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →