Google PCD: Test, ingegneria della qualità e gestione sicura dei rilasci — Guida allo studio

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

Fa parte della Google Professional Cloud Developer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

I team ad alta velocità su Google Cloud abbinano test rigorosi a una delivery progressiva per ridurre il rischio, accelerando al contempo il cambiamento. Una strategia robusta spazia dai test unitari a quelli end-to-end, simulazione realistica di dati e dipendenze, quality gate automatizzati e pattern di rilascio controllati come canary e blue-green. Osservabilità, ownership e una verifica post-rilascio disciplinata chiudono il cerchio. Questa sezione descrive in dettaglio come progettare per l’affidabilità, isolare il rischio e promuovere in sicurezza le build tra i vari ambienti con i servizi di Google Cloud.

Strategia di test e gestione dei dati

Piramide dei test e tipi di test

Test unitari: Verifica rapida e isolata di funzioni, classi e piccoli moduli. Dovrebbero costituire la maggior parte della suite di test. Eseguirli a ogni commit e pull request.
Test di integrazione: Validano le interazioni tra i componenti, come l’applicazione e il suo datastore o la sua coda. Utilizzare gli emulatori di Google Cloud dove disponibili.
Test di contratto (contract test): I contratti guidati dal consumatore (consumer-driven contract) per i microservizi prevengono modifiche che potrebbero rompere le API. Validare il comportamento del provider rispetto allo schema e alla semantica attesi dal consumer prima dell’integrazione. Utilizzare Pact o strumenti simili; versionare le API e pubblicare gli schemi.
Test end-to-end: Esercitano il percorso completo del sistema utilizzando configurazione, identità e policy di rete simili a quelle di produzione. Limitarne il numero, parallelizzarli ed eseguirli in ambienti di pre-produzione.
Smoke test: Sonde minime che confermano il corretto comportamento di dipendenze critiche, route e health check dopo ogni deploy. Sono la prima verifica da effettuare dopo il deployment.

Gestione dei dati di test, isolamento, riproducibilità e parità degli ambienti

Popolamento dei dati (data seeding): Generare dataset piccoli e deterministici per i test unitari e dataset più grandi e rappresentativi per i test di integrazione/performance. Popolare i dati da fixture inserite nel controllo di versione.
Isolamento: Assicurarsi che i test non condividano lo stato. Utilizzare database effimeri, namespace GKE isolati e prefissi unici per gli oggetti di Cloud Storage. Per SQL, creare schemi per ogni test; per Pub/Sub, generare topic/sottoscrizioni temporanei.
Riproducibilità: Fissare le versioni delle dipendenze, rendere le build ermetiche e fissare i seed casuali. Archiviare i container di test con i loro digest in Artifact Registry.
Parità degli ambienti: Standardizzare le immagini dei container e l’infrastructure-as-code tra gli ambienti di dev, QA, staging e produzione. Mantenere la configurazione fuori dalle immagini e utilizzare metadati e segreti specifici per ogni ambiente. Per Compute Engine, archiviare i valori specifici per il deployment nei metadati del template di istanza; per la parità tra progetti, configurare una chiave di metadati per l’ambiente e leggerla all’avvio per selezionare la configurazione specifica dell’ambiente.

Mock, emulatori, fake e servizi sandbox

Mock/stub: Sostituire i collaboratori a livello unitario per isolare la logica ed eliminare le chiamate di rete. Evitare un uso eccessivo dei mock; asserire sul comportamento, non sui dettagli di implementazione.
Emulatori: Preferire gli emulatori ufficiali per i test di integrazione. Esempi: gli emulatori di Firestore/Datastore, Pub/Sub, Spanner e Bigtable. Offrono fedeltà alle API senza costi cloud e accelerano la CI.
Fake: Quando non esiste un emulatore, eseguire fake locali leggeri (ad esempio, un fake object store) o servizi sandbox condivisi con forte isolamento e quote.
Simulazione delle dipendenze esterne: Per le API di terze parti, eseguire fake basati su contratti dietro un service mesh o un API gateway; configurare timeout, tentativi (retry) e chaos injection per testare la gestione dei fallimenti.

Modalità di fallimento comuni e compromessi

Un’eccessiva dipendenza dai test end-to-end rallenta l’iterazione; investire in test unitari e di contratto per individuare i problemi prima.
Gli ambienti di test condivisi e di lunga durata accumulano deviazioni (drift) e inquinamento dei dati. Preferire ambienti effimeri e procedure di setup/teardown idempotenti.
Gli emulatori potrebbero non rispecchiare perfettamente la produzione. Utilizzare test E2E in un ambiente di staging con servizi reali prima della promozione.

Breve esempio di Cloud Build per separare le fasi che falliscono

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

Passaggi separati assicurano che la cronologia della build individui con precisione se il fallimento è avvenuto in fase di compilazione/test unitari, build o integrazione.

Test non funzionali e qualità del codice

Test delle prestazioni

Tipi: Test di carico (load, a regime), di stress (oltre il picco), di durata (soak, lunga durata) e di capacità.
Strumenti: Utilizzare Cloud Monitoring per SLO e alerting, Cloud Trace per l’analisi dettagliata della latenza e Cloud Profiler per individuare i percorsi critici (hot path). Per GKE, scalare con Cluster Autoscaler e HPA; per i worker di Pub/Sub, l’HPA basato su metriche esterne gestisce la scalabilità guidata dai picchi di traffico.
Test in produzione: Utilizzare dark launch e request mirroring per valutare in sicurezza i nuovi backend con il traffico di produzione. L’External HTTP(S) Load Balancing supporta il request mirroring; Anthos Service Mesh supporta il traffic shadowing.

Test di sicurezza

SAST/scansione dei segreti: Eseguire analizzatori statici nella CI e rifiutare le credenziali hardcoded. Archiviare i segreti in Secret Manager con accesso basato sul principio del privilegio minimo (least-privilege).
Scansione delle dipendenze e delle immagini: Abilitare Container Analysis su Artifact Registry. Applicare le policy con Binary Authorization, richiedendo attestazioni che certifichino l’assenza di vulnerabilità critiche prima del deployment.
DAST: Eseguire la scansione degli ambienti di staging con scanner autenticati e bloccare i rilasci in caso di scoperte critiche.

Accessibilità e regressione

Accessibilità: Integrare controlli di accessibilità (a11y) automatizzati (ad esempio, Lighthouse CI) nei controlli pre-merge non bloccanti; risolvere i problemi prima del rilascio.
Suite di regressione: Mantenere suite di regressione curate e stabili per i percorsi critici. Eseguire smoke test a ogni deploy e la regressione completa sui candidati al rilascio (release candidate).

Analisi statica, quality gate e code review

Analisi statica: Configurare linter e formattatori appropriati per il linguaggio come controlli pre-submit. Utilizzare Bazel o strumenti simili per parallelizzare.
Quality gate: Far fallire le build al superamento delle soglie (copertura, complessità, errori di lint). Pubblicare i risultati nei log di Cloud Build.
Code review: Richiedere la revisione da parte di due persone per le modifiche rischiose, l’uso di CODEOWNERS per i percorsi critici e la CI pre-submit sui tag utilizzati per i rilasci.
Supply chain: Generare SBOM, firmare gli artefatti e archiviare la loro provenienza. Imporre i controlli di attestazione in Binary Authorization.

Delivery progressiva e rilasci sicuri

Strategie di deployment

Rolling: Sostituisce pod o istanze in modo incrementale. Basso rischio per servizi stateless; da abbinare a readiness probe e impostazioni di surge/availability.
Blue-green: Viene creato un ambiente nuovo completo, si eseguono le verifiche e poi si sposta il traffico. Consente un rollback istantaneo ripristinando la configurazione del load balancer. Ideale quando è necessario un fallback immediato.
Canary: Sposta gradualmente una piccola percentuale di traffico verso la nuova versione monitorando le metriche chiave. Promozione automatica se lo stato è integro (healthy); rollback in caso di regressioni.
Traffic splitting: Instrada il traffico per percentuale o attributi (header, cookie, user-agent) con GKE più Anthos Service Mesh, oppure utilizza la suddivisione integrata in Cloud Run e App Engine.

Feature flag e sperimentazione

Feature flag: Disaccoppiano il deploy dal rilascio. Utilizzare i flag per rollout graduali, kill switch e per attivare/disattivare esperimenti. Archiviarli centralmente (ad esempio, un servizio gestito per i flag o un config store protetto da IAM). Mantenere breve il ciclo di vita dei flag e rimuovere quelli non più necessari.
Dark launch: Rilasciare funzionalità disabilitate; validarle tramite utenti interni o traffico sintetico.
Shadow traffic: Replica le richieste di produzione verso i nuovi servizi senza impattare gli utenti; confronta le risposte per rilevare regressioni.
Esperimenti controllati: Implementare routing A/B o multivariato con le regole del service mesh. Per esperimenti basati su user-agent, instradare tramite corrispondenza degli header.

Gate, approvazioni, rollback e osservabilità

Deployment gate: Aggiungere test di integrazione pre-deploy e smoke/health check post-deploy. Per la promozione tra ambienti, utilizzare trigger basati su tag per separare la build dal rilascio.
Approvazioni manuali: Richiedere l’approvazione umana in fasi cardine, come il passaggio da staging a produzione. Cloud Deploy supporta passaggi di approvazione manuale per ogni target.
Rollback automatico: Definire SLO e policy di alerting; quando un canary viola le soglie di error rate o latenza, eseguire automaticamente il rollback invocando l’API di deploy. Mantenere i rollback veloci e ben collaudati.
Osservabilità dei rilasci: Strumentare i rilasci con etichette di versione nelle metriche e nei log. Esportare le metriche di Prometheus in Cloud Monitoring e creare metriche basate su log per i pattern di errore, al fine di correlare la telemetria in modo economicamente efficiente.

Breve esempio di routing ASM per un canary basato su header

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

Affidabilità dei test, cicli di feedback e disciplina post-rilascio

Gestione e affidabilità dei test instabili (flaky test)

Rilevamento e quarantena: Tracciare l’instabilità dei test nel tempo; mettere in quarantena i test noti per essere instabili e non bloccare i rilasci a causa loro, dando priorità alla loro correzione.
Timeout e tentativi (retry): Aggiungere timeout ragionevoli; consentire un singolo tentativo (retry) per sospette instabilità dell’infrastruttura, non per errori di logica.
Build ermetiche: Evitare chiamate di rete nei test unitari; fissare le versioni degli artefatti (pinning) e usare emulatori per ridurre il non determinismo.
Parallelizzazione: Suddividere (shard) i test in Cloud Build su più passaggi o worker per minimizzare la latenza del feedback.

Cicli di feedback

Trigger di CI: Eseguire test unitari e di integrazione a ogni commit su main e per ogni pull request. Usare passaggi separati in Cloud Build in modo che la cronologia della build identifichi la fase fallita. Creare trigger di rilascio su tag Git, non a ogni commit, per controllare i deployment.
Verifica progressiva: Promuovere automaticamente da dev a test dopo un deployment riuscito, sottoscrivendo le notifiche Pub/Sub di Cloud Deploy e invocando la promozione sugli eventi SUCCEEDED.
Promozione basata su metriche: Per i canary, condizionare l’aumento graduale del traffico (ramp-up) alle metriche di Cloud Monitoring e agli SLO.

Documentazione di rilascio, ownership e verifica post-rilascio

Documentazione: Mantenere note di rilascio, runbook e procedure di rollback accanto al codice. Tracciare i ticket di modifica con link a commit, immagini e versioni degli ambienti.
Ownership: Definire le rotazioni di reperibilità (on-call) e i proprietari dei componenti; imporre l’uso di CODEOWNERS per le aree sensibili. Assicurare che ci siano approvatori chiari per le promozioni in produzione.
Verifica post-rilascio: Eseguire suite di smoke test, assicurarsi che gli error budget rimangano stabili e verificare le dashboard tramite tag di versione. Confermare che i report di sicurezza e vulnerabilità rimangano entro i limiti delle policy. Se sorgono problemi, eseguire prima il rollback, poi l’analisi della causa radice (root-cause).

Scenario di un problema pratico

Il team della piattaforma di Acme Retail sta standardizzando i test e i rilasci per un’applicazione a microservizi basata su GKE che include anche un frontend web stateless su Cloud Run. Devono garantire un feedback rapido, bloccare le build rischiose e distribuire nuove funzionalità in sicurezza, utilizzando il traffico live per valutare le prestazioni.

Approccio

Separare le fasi di build e test in Cloud Build

Motivazione: Utilizzare passaggi distinti per compilare, eseguire i test unitari, creare il container ed eseguire i test di integrazione, in modo che la cronologia della build individui la fase di fallimento e gli sviluppatori ricevano rapidamente un feedback utile.
Esempio:

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

Eseguire i test di integrazione su emulatori e namespace effimeri

Motivazione: Per i worker Pub/Sub e i servizi basati su Firestore, utilizzare gli emulatori di Pub/Sub e Firestore; per i servizi che richiedono policy a livello di cluster, creare un namespace GKE effimero per ogni build con topic e service account temporanei tramite Workload Identity. Questo fornisce isolamento, velocità e costi ridotti, mantenendo l’affidabilità.

Imporre quality gate di sicurezza con Artifact Registry e Binary Authorization

Motivazione: Abilitare la scansione delle vulnerabilità al push dell’immagine, far fallire la pipeline in caso di CVE critiche e richiedere attestazioni in Binary Authorization prima di effettuare il deployment su GKE. Questo impedisce il deployment di immagini con vulnerabilità critiche note.

Utilizzare trigger di rilascio basati su tag Git

Motivazione: I trigger di Cloud Build basati su tag (ad esempio, vX.Y.Z) consentono rilasci automatizzati solo per i commit esplicitamente taggati, evitando deployment accidentali in produzione a ogni commit su main.

Delivery progressiva con Cloud Deploy e Anthos Service Mesh

Motivazione: Definire una pipeline di Cloud Deploy con target dev, test e prod. Utilizzare l’approvazione manuale per controllare la promozione a prod. Per prod, usare una strategia canary con ASM per spostare il traffico al 5%, 25%, 50%, 100% monitorando gli SLO. Cloud Deploy si sottoscrive agli hook di verifica; un fallimento interrompe o esegue il rollback automatico del canary tramite API.

Osservabilità e hook di rollback automatizzati

Motivazione: Esportare le metriche di Prometheus in Cloud Monitoring e creare metriche basate su log per le firme degli errori. Configurare policy di avviso su metriche etichettate per versione. Una Cloud Function sottoscritta agli avvisi chiama l’API di Cloud Deploy per mettere in pausa o eseguire il rollback del rollout. Questo collega i segnali oggettivi sullo stato di salute al controllo del deployment.

Shadow traffic e validazione A/B per il frontend su Cloud Run

Motivazione: Utilizzare il mirroring delle richieste (request mirroring) a livello di load balancer HTTP(S) esterno per inviare le richieste di produzione alla nuova revisione di Cloud Run senza impattare gli utenti. Successivamente, utilizzare la suddivisione del traffico (traffic-splitting) di Cloud Run per spostare piccole percentuali di traffico e confrontare le metriche di latenza/errore prima del passaggio completo (cutover).

Fallback blue-green per i servizi di backend critici

Motivazione: Per i servizi che richiedono un rollback istantaneo, mantenere deployment blue e green dietro un unico servizio di backend. Validare l’ambiente green con smoke test e test di contratto, quindi invertire il traffico. Ripristinare istantaneamente la versione precedente se compaiono anomalie.

Verifica e documentazione post-rilascio

Motivazione: Dopo la promozione, eseguire smoke test automatizzati, verificare le dashboard per versione di rilascio e aggiornare le note di rilascio con i digest degli artefatti e la cronologia del rollout. L’ownership e il team di reperibilità (on-call) ricevono il passaggio di consegne; se gli error budget si esauriscono, eseguire prima il rollback, poi condurre un’analisi post-mortem “blameless” (senza colpevolizzazione).

Questo approccio fornisce un feedback rapido e affidabile nella CI, impone sicurezza e qualità e utilizza strategie di rollout sicure e osservabili che supportano sia esperimenti basati su attributi sia rollback istantanei quando necessario.

← Prestazioni · Tutti i domini · Costi →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →