Google PCD: Testen, Quality Engineering en veilig releasemanagement — Studiegids

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

Onderdeel van de Google Professional Cloud Developer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

High-velocity teams op Google Cloud combineren rigoureus testen met progressieve delivery om risico’s te verminderen en tegelijkertijd veranderingen te versnellen. Een robuuste strategie omvat alles van unit- tot end-to-end-tests, realistische data- en afhankelijkheidssimulatie, geautomatiseerde quality gates en gecontroleerde releasepatronen zoals canary en blue-green. Observability, eigenaarschap en gedisciplineerde verificatie na de release sluiten de cirkel. Dit gedeelte beschrijft hoe u kunt ontwerpen voor betrouwbaarheid, risico’s kunt isoleren en builds veilig kunt promoten over verschillende omgevingen met Google Cloud-services.

Teststrategie en Datamanagement

Testpiramide en testtypes

Unit tests: Snelle, geïsoleerde verificatie van functies, klassen en kleine modules. Deze zouden het grootste deel van de testsuite moeten uitmaken. Voer ze uit bij elke commit en pull request.
Integratietests: Valideren de interacties tussen componenten, zoals de applicatie en haar datastore of queue. Gebruik Google Cloud-emulators waar beschikbaar.
Contracttests: Consumer-driven contracts voor microservices voorkomen ‘breaking’ API-wijzigingen. Valideer het gedrag van de provider tegen het verwachte schema en de semantiek van de consumer vóór de integratie. Gebruik Pact of vergelijkbare tools; versioneer je API en publiceer schema’s.
End-to-end-tests: Testen het volledige systeempad met een productie-achtige configuratie, identiteit en netwerkbeleid. Beperk hun aantal, voer ze parallel uit en draai ze op pre-productieomgevingen.
Smoke tests: Minimale controles die na elke deploy bevestigen dat kritieke afhankelijkheden, routes en health checks correct werken. Dit zijn je eerste verificaties na de deployment.

Testdatamanagement, isolatie, reproduceerbaarheid en omgevingspariteit

Data seeding: Genereer kleine, deterministische datasets voor unit tests en grotere, representatieve datasets voor integratie-/performancetests. Seed vanuit fixtures die zijn ingecheckt in source control.
Isolatie: Zorg ervoor dat tests geen state delen. Gebruik efemere databases, geïsoleerde GKE-namespaces en unieke prefixes voor Cloud Storage-objecten. Maak voor SQL per test schema’s aan; genereer voor Pub/Sub tijdelijke topics/subscriptions.
Reproduceerbaarheid: Pin de versies van afhankelijkheden, maak builds hermetisch en zet random seeds vast. Sla testcontainers met digests op in Artifact Registry.
Omgevingspariteit: Standaardiseer container images en infrastructure-as-code voor dev, QA, staging en productie. Houd configuratie buiten de images en gebruik omgevingsspecifieke metadata en secrets. Sla voor Compute Engine per-deployment-waarden op in de metadata van instance templates; configureer voor pariteit tussen projecten een omgevingsmetadata-key en lees deze bij het opstarten uit om de omgevingsspecifieke configuratie te selecteren.

Mocking, emulators, fakes en sandbox-services

Mocks/stubs: Vervang collaborators op unit-niveau om logica te isoleren en netwerk-calls te vermijden. Vermijd overmatig mocken; doe asserts op gedrag, niet op implementatiedetails.
Emulators: Geef de voorkeur aan officiële emulators voor integratietests. Voorbeelden: Firestore/Datastore, Pub/Sub, Spanner en Bigtable emulators. Ze bieden API-getrouwheid zonder cloudkosten en versnellen CI.
Fakes: Wanneer er geen emulator bestaat, gebruik dan lichtgewicht lokale fakes (bijvoorbeeld een fake object store) of gedeelde sandbox-services met sterke isolatie en quota’s.
Simulatie van externe afhankelijkheden: Gebruik voor API’s van derden contract-gebaseerde fakes achter een service mesh of API gateway; configureer timeouts, retries en chaos injection om de afhandeling van fouten te testen.

Veelvoorkomende faalmodi en afwegingen

Te veel vertrouwen op end-to-end-tests vertraagt de iteratie; investeer in unit- en contracttests om problemen eerder te ondervangen.
Gedeelde, langlevende testomgevingen verzamelen ‘drift’ en datavervuiling. Geef de voorkeur aan efemere omgevingen en een idempotente setup/teardown.
Emulators zijn mogelijk geen perfecte afspiegeling van de productieomgeving. Gebruik gefaseerde E2E-tests met echte services vóór promotie.

Kort Cloud Build-voorbeeld om falende stages te scheiden

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']

Afzonderlijke stappen zorgen ervoor dat de buildgeschiedenis precies aangeeft of de compilatie/unit-test, de build of de integratie is mislukt.

Niet-functioneel testen en codekwaliteit

Performancetesten

Types: Load (steady-state), stress (boven piekbelasting), soak (lange duur) en capaciteitstests.
Tooling: Gebruik Cloud Monitoring voor SLO’s en alerting, Cloud Trace voor latency-analyse en Cloud Profiler om ‘hot paths’ te identificeren. Voor GKE, schaal met Cluster Autoscaler en HPA; voor Pub/Sub-workers, handelt HPA op basis van externe metrics de schaling af die door pieken wordt veroorzaakt.
Testen in productie: Gebruik dark launches en request mirroring om nieuwe backends veilig te evalueren met productieverkeer. External HTTP(S) Load Balancing ondersteunt request mirroring; Anthos Service Mesh ondersteunt traffic shadowing.

Securitytesten

SAST/secret scanning: Voer statische analyzers uit in CI en weiger hardgecodeerde credentials. Sla secrets op in Secret Manager met least-privilege toegang.
Afhankelijkheids- en image-scanning: Schakel Container Analysis in op Artifact Registry. Dwing beleid af met Binary Authorization, waarbij attesten vereist zijn dat er geen kritieke kwetsbaarheden bestaan vóór de deployment.
DAST: Scan staging-omgevingen met geauthenticeerde scanners en blokkeer releases bij kritieke bevindingen.

Toegankelijkheid en regressie

Toegankelijkheid: Integreer geautomatiseerde a11y-checks (bijvoorbeeld Lighthouse CI) in niet-blokkerende pre-merge-controles; los problemen op vóór de release.
Regressiesuites: Onderhoud gecureerde, stabiele regressiesuites voor kritieke ‘journeys’. Voer smoke tests uit bij elke deploy en een volledige regressietest op release candidates.

Statische analyse, quality gates en code review

Statische analyse: Configureer taalspecifieke linters en formatters als pre-submit-controles. Gebruik Bazel of iets vergelijkbaars om te parallelliseren.
Quality gates: Laat builds falen bij het overschrijden van drempelwaarden (coverage, complexiteit, lint-fouten). Publiceer resultaten naar de Cloud Build-logs.
Code review: Vereis een review door twee personen voor risicovolle wijzigingen, CODEOWNERS voor kritieke paden en presubmit CI op tags die voor releases worden gebruikt.
Supply chain: Genereer SBOMs, onderteken artefacten en sla herkomstinformatie (provenance) op. Dwing attestcontroles af in Binary Authorization.

Progressive Delivery en Veilige Releases

Deploymentstrategieën

Rolling: Vervang pods of instances stapsgewijs. Laag risico voor stateless services; combineer met readiness probes en surge/availability-instellingen.
Blue-green: Zet een volledig nieuwe omgeving op, voer verificatie uit en schakel dan het verkeer om. Maakt onmiddellijke rollback mogelijk door de load balancer terug te draaien. Ideaal wanneer je een directe fallback-optie nodig hebt.
Canary: Leid geleidelijk een klein percentage van het verkeer naar de nieuwe versie terwijl je belangrijke metrics in de gaten houdt. Automatiseer promotie als de status goed is; rol terug bij regressies.
Traffic splitting: Routeer op basis van percentage of attributen (headers, cookies, user-agent) met GKE plus Anthos Service Mesh, of gebruik de ingebouwde splitting in Cloud Run en App Engine.

Feature flags en experimenten

Feature flags: Ontkoppel de implementatie (deploy) van de release. Gebruik flags voor geleidelijke uitrol, kill switches en toggles voor experimenten. Sla ze centraal op (bijvoorbeeld een beheerde flag-service of een config store beveiligd met IAM). Houd de levensduur van flags kort en verwijder overbodige flags.
Dark launches: Implementeer features uitgeschakeld; valideer via interne gebruikers of synthetisch verkeer.
Shadow traffic: Spiegel productieverzoeken naar nieuwe services zonder impact op gebruikers; vergelijk de responses om regressies te detecteren.
Gecontroleerde experimenten: Implementeer A/B- of multivariate routing met service mesh-regels. Voor experimenten op basis van user-agent, routeer op basis van een header-match.

Gates, goedkeuringen, rollback en observability

Deployment gates: Voeg predeploy-integratietests en postdeploy-smoke/health-checks toe. Gebruik voor omgevingspromotie op tags gebaseerde triggers om de build van de release te scheiden.
Handmatige goedkeuringen: Vereis menselijke goedkeuring bij mijlpalen, zoals van staging naar productie. Cloud Deploy ondersteunt handmatige goedkeuringsstappen per target.
Automatische rollback: Definieer SLO’s en alert-beleidsregels; wanneer een canary de drempelwaarden voor error rate of latency overschrijdt, rol dan automatisch terug door de deploy-API aan te roepen. Zorg dat rollbacks snel en goed geoefend zijn.
Release observability: Instrumenteer releases met versielabels in metrics en logs. Exporteer Prometheus-metrics naar Cloud Monitoring en maak op logs gebaseerde metrics voor foutpatronen om telemetrie kosteneffectief te correleren.

Kort ASM-routingvoorbeeld voor een op headers gebaseerde canary

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

Betrouwbaarheid van tests, feedbackloops en discipline na de release

Beheer en betrouwbaarheid van onstabiele (flaky) tests

Detecteer en plaats in quarantaine: Volg de onstabiliteit van tests over tijd; plaats bekende onstabiele tests in quarantaine en blokkeer releases hier niet op, terwijl je prioriteit geeft aan het oplossen ervan.
Timeouts en retries: Voeg verstandige timeouts toe; sta één enkele retry toe voor vermoedelijke infrastructuurproblemen, niet voor logische fouten.
Hermetische builds: Vermijd netwerkoproepen in unit tests; pin artefacten en gebruik emulators om non-determinisme te verminderen.
Parallellisatie: Verdeel (shard) tests in Cloud Build over meerdere stappen of workers om de feedbacklatentie te minimaliseren.

Feedbackloops

CI-triggers: Voer unit- en integratietests uit bij elke commit naar de main-branch en bij pull requests. Gebruik afzonderlijke Cloud Build-stappen zodat de build-geschiedenis de falende fase identificeert. Maak release-triggers op Git-tags, niet op elke commit, om implementaties te beheersen.
Progressieve verificatie: Promoveer automatisch van dev naar test na een succesvolle implementatie door je te abonneren op Cloud Deploy Pub/Sub-notificaties en de promotie aan te roepen bij SUCCEEDED-events.
Metric-gestuurde promotie: Voor canary-releases, bewaak de verkeerstoename op basis van Cloud Monitoring-metrics en SLO’s.

Releasedocumentatie, eigenaarschap en verificatie na de release

Documentatie: Onderhoud release notes, runbooks en rollback-procedures naast de code. Volg change tickets met links naar commits, images en omgevingsversies.
Eigenaarschap: Definieer wachtdienstschema’s en component-eigenaren; dwing CODEOWNERS af voor gevoelige onderdelen. Zorg voor duidelijke goedkeurders voor promoties naar productie.
Verificatie na de release: Voer smoke-testsuites uit, zorg ervoor dat error budgets gezond blijven en verifieer dashboards op basis van de versietag. Bevestig dat beveiligings- en kwetsbaarheidsrapporten binnen het beleid blijven. Als er problemen optreden, voer dan eerst een rollback uit en analyseer daarna de hoofdoorzaak.

Praktisch Probleemscenario

Het platformteam van Acme Retail standaardiseert het testen en de releases voor een op GKE gebaseerde microservices-applicatie die ook een stateless web-frontend op Cloud Run omvat. Ze moeten zorgen voor snelle feedback, risicovolle builds blokkeren en nieuwe functies veilig uitrollen, terwijl ze live verkeer gebruiken om de prestaties te evalueren.

Aanpak

Scheid build- en testfasen in Cloud Build

Rationale: Gebruik afzonderlijke stappen om te compileren, unit tests uit te voeren, de container te bouwen en integratietests uit te voeren, zodat de build-geschiedenis de falende fase precies aanwijst en ontwikkelaars snel bruikbare feedback krijgen.
Voorbeeld:

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']

Voer integratietests uit tegen emulators en tijdelijke (ephemeral) namespaces

Rationale: Gebruik voor Pub/Sub-workers en door Firestore ondersteunde services de Pub/Sub- en Firestore-emulators; voor services die clusterbeleid vereisen, start je per build een tijdelijke GKE-namespace op met tijdelijke topics en service accounts via Workload Identity. Dit zorgt voor isolatie, snelheid en lage kosten met behoud van nauwkeurigheid.

Dwing beveiligingskwaliteitspoorten af met Artifact Registry en Binary Authorization

Rationale: Schakel vulnerability scanning in bij het pushen van een image, laat de pipeline falen bij kritieke CVE’s en vereis attestations in Binary Authorization voordat je naar GKE implementeert. Dit voorkomt de implementatie van images met bekende kritieke kwetsbaarheden.

Gebruik op Git-tags gebaseerde release-triggers

Rationale: Cloud Build-triggers op tags (bijvoorbeeld vX.Y.Z) maken geautomatiseerde releases alleen mogelijk voor expliciet getagde commits, waardoor onbedoelde productie-implementaties vanaf elke commit naar de main-branch worden vermeden.

Progressive delivery met Cloud Deploy en Anthos Service Mesh

Rationale: Definieer een Cloud Deploy-pipeline met dev-, test- en prod-targets. Gebruik handmatige goedkeuring om de promotie naar prod te bewaken. Gebruik voor prod een canary-strategie met ASM om het verkeer te verschuiven naar 5%, 25%, 50%, 100% terwijl je de SLO’s monitort. Cloud Deploy abonneert zich op verificatie-hooks; een fout stopt of rolt de canary automatisch terug via de API.

Observeerbaarheid en geautomatiseerde rollback-hooks

Rationale: Exporteer Prometheus-metrics naar Cloud Monitoring en maak op logs gebaseerde metrics voor foutsiganleringen. Configureer alerting-beleid op metrics met versielabels. Een Cloud Function die is geabonneerd op alerts, roept de Cloud Deploy API aan om de uitrol te pauzeren of terug te draaien. Dit koppelt objectieve gezondheidssignalen aan de controle over de implementatie.

Shadow traffic en A/B-validatie voor de Cloud Run-frontend

Rationale: Gebruik request mirroring op de externe HTTP(S) load balancer om productieverzoeken naar de nieuwe Cloud Run-revisie te sturen zonder impact op gebruikers. Gebruik vervolgens de traffic-splitting van Cloud Run om kleine percentages te verschuiven en de latency/error-metrics te vergelijken vóór de volledige omschakeling.

Blue-green fallback voor kritieke backend-services

Rationale: Voor services die een onmiddellijke rollback vereisen, onderhoud je blue- en green-implementaties achter één enkele backend service. Valideer de green-omgeving met smoke- en contracttests en zet vervolgens het verkeer om. Draai onmiddellijk terug als er anomalieën verschijnen.

Verificatie en documentatie na de release

Rationale: Voer na de promotie geautomatiseerde smoke tests uit, verifieer dashboards op basis van de releaseversie en werk de release notes bij met artifact digests en de uitrolgeschiedenis. Eigenaarschap en de wachtdienst ontvangen de overdracht; als error budgets opraken, voer dan eerst een rollback uit en voer daarna een schuldvrije analyse uit.

Deze aanpak levert snelle, betrouwbare feedback in CI, dwingt beveiliging en kwaliteit af, en maakt gebruik van veilige, observeerbare uitrolstrategieën die zowel attribuut-gebaseerde experimenten als onmiddellijke rollbacks ondersteunen wanneer dat nodig is.

← Prestaties · Alle domeinen · Kosten →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →