Continuous integration con Cloud Build

Cloud Build è il servizio serverless di continuous integration di Google Cloud. Un trigger reagisce a eventi del repository (push su un branch, apertura di una pull request, creazione di un tag) e avvia una build definita in un file di configurazione, dove ogni step gira in un container isolato: compilazione, unit e integration test, linting, build dell’immagine e push verso Artifact Registry. Il taglio da esame è capire che Cloud Build fa CI, non CD: orchestra la costruzione e la validazione dell’artefatto, non la promozione tra ambienti. Una pipeline CI ben disegnata fallisce presto (fail-fast) e resta veloce, così da ridurre il toil e mantenere alta la frequenza di rilascio. Cloud Build può inoltre generare build provenance (attestazioni SLSA) che diventano la base per il gating di sicurezza a valle.

Artifact Registry e la supply chain

Artifact Registry è il repository gestito e regionale per immagini container e pacchetti (Maven, npm, Python, ecc.); è il successore di Container Registry. Oltre allo storage, integra il vulnerability scanning tramite Artifact Analysis, che analizza le immagini al push e continua a rivalutarle nel tempo quando emergono nuove CVE. Criteri di scelta tipici: separare i repository per ambiente o per team, deployare per digest (immutabile) invece che per tag mutabile, e usare il risultato dello scanning come segnale di qualità prima della promozione. La provenienza e le attestazioni prodotte in fase di build viaggiano con l’immagine e vengono verificate al momento del deploy.

Continuous delivery con Cloud Deploy

Cloud Deploy è il servizio gestito di continuous delivery. Si definisce una delivery pipeline con target ordinati (per esempio dev → staging → prod); una release rappresenta una specifica versione dell’artefatto che viene promossa attraverso i target sotto forma di rollout. Sui target sensibili si configurano approvazioni manuali, mentre il rollback riporta un target al rollout precedente in modo rapido e ripetibile — un fattore chiave per ridurre l’MTTR. Cloud Deploy usa Skaffold e può deployare su GKE, Cloud Run e GKE Enterprise, con una fase di verify per eseguire test post-deploy. L’errore da evitare all’esame è usare Cloud Build per orchestrare le promozioni tra ambienti: quel compito è di Cloud Deploy.

Strategie di rilascio e Binary Authorization

La scelta della strategia bilancia affidabilità e velocità. Il canary espone la nuova versione a una quota progressiva di traffico in fasi percentuali (Cloud Deploy supporta nativamente il canary), così da limitare il blast radius e osservare gli SLI prima del 100%. Il blue/green mantiene due ambienti e sposta il traffico in modo atomico: rollback quasi istantaneo, ma costo infrastrutturale doppio. Il rolling update sostituisce le istanze gradualmente ed è il comportamento predefinito di un Deployment GKE. Il traffic splitting distribuisce il traffico per percentuale tra revisioni — nativo su Cloud Run. Legare l’aggressività del rollout all’error budget è il ragionamento SRE atteso: budget ampio → rilasci più rapidi. Binary Authorization è il controllo di sicurezza a deploy-time: una policy con admission rule impedisce il deploy di immagini prive delle attestazioni richieste dagli attestor, garantendo che arrivino in produzione solo immagini fidate.

Trappole tipiche d’esame

  • Serve orchestrare il passaggio da staging a prod con approvazione → soluzione: Cloud Deploy con delivery pipeline e approvazioni sui target, non uno script in Cloud Build.
  • Bloccare in produzione immagini non verificate → soluzione: Binary Authorization con policy e attestazioni; il solo vulnerability scanning segnala ma non impedisce il deploy.
  • Rollback il più rapido possibile a costo di più risorse → soluzione: blue/green per lo switch atomico; il canary riduce il rischio ma non offre un ripristino istantaneo.
  • Ridurre il blast radius di una release rischiosa → soluzione: canary con incrementi percentuali e osservazione degli SLI, non un rolling update indistinto.
  • Rilevare nuove CVE su immagini già pubblicate → soluzione: Artifact Analysis con scanning continuo in Artifact Registry, non una scansione una tantum al build.
  • Distribuire traffico tra due versioni su Cloud Run → soluzione: traffic splitting per percentuale tra revisioni, non un secondo servizio dietro un load balancer gestito a mano.