Sviluppo, source control e dipendenze

Il Professional Cloud Developer parte dai fondamentali: codice versionato, build riproducibili e dipendenze esplicite. Lavora con un source control (Git, tipicamente Cloud Source Repositories o GitHub/GitLab collegati) usando branch protection e commit piccoli che abilitano una CI incrementale. Le dipendenze vanno bloccate con lockfile per garantire build deterministiche; le vulnerabilità si intercettano con la vulnerability scanning di Artifact Registry, non a mano. I secret non stanno mai nel repository né nelle env in chiaro: vivono in Secret Manager e vengono letti a runtime tramite l’identità del servizio. Per l’accesso ai servizi Google preferisci Workload Identity o l’impersonation di service account rispetto alle service account key esportate, credenziali statiche difficili da ruotare e da revocare.

Containerizzazione: Dockerfile vs Cloud Native Buildpacks

Due strade portano all’immagine. Il Dockerfile dà controllo totale: multi-stage build per separare la fase di compilazione dall’immagine finale, base image minimale (distroless o slim) per ridurre superficie d’attacco e dimensione, layer ordinati dal meno al più volatile per massimizzare la cache. Sceglilo quando servono step di build particolari, tool di sistema o un’ottimizzazione fine dei layer.

I Cloud Native Buildpacks (via il tool pack, o direttamente da Cloud Build e Cloud Run) producono l’immagine dal codice sorgente senza scrivere né mantenere un Dockerfile: rilevano il linguaggio, applicano best practice e centralizzano il patching delle base image. Sono la scelta giusta quando vuoi standardizzare molte app e ridurre la manutenzione, senza requisiti particolari sull’immagine. Il trade-off è meno controllo sul contenuto esatto dei layer.

CI con Cloud Build e Artifact Registry

Cloud Build esegue la pipeline come sequenza di step, ognuno un container, definiti in un file di configurazione. I trigger partono su push, tag o pull request verso il repo. Un flusso tipico: build dell’immagine (o buildpack) → test → push su Artifact Registry → deploy. Cloud Build gira con una service account: assegnale solo i ruoli necessari (least privilege) e usa Secret Manager per i valori sensibili invece di scriverli nel file di build.

Artifact Registry è il registro gestito che sostituisce il vecchio Container Registry: ospita immagini container ma anche pacchetti (Maven, npm, Python, apt/yum). Preferiscilo per repository regionali (latenza e data residency), controllo IAM granulare per singolo repo, vulnerability scanning integrato e supporto ai formati non-container. Tagga le immagini con lo short SHA del commit per tracciabilità e rollback deterministico, evitando di affidarti solo al tag mutabile latest.

Testing ed emulatori locali

Applica la testing pyramid: molti unit test veloci che isolano la logica, meno integration test che verificano l’interazione tra componenti e servizi, pochi end-to-end test sul percorso completo. In CI gli unit test girano come step di Cloud Build che blocca la pipeline se falliscono, dando feedback rapido prima del deploy.

Per testare l’interazione con i servizi Google senza toccare risorse reali (costo, latenza, side effect), usa gli emulatori locali: Firestore, Pub/Sub, Bigtable, Spanner e altri sono forniti dal Cloud SDK (gcloud CLI). Puntando l’SDK all’endpoint dell’emulatore tramite una variabile d’ambiente host, esegui integration test deterministici e offline, ideali anche dentro la pipeline. Ricorda però che l’emulatore non replica IAM, quote e comportamenti di scala del servizio reale: resta uno strumento di sviluppo e test funzionale, non di validazione di produzione.

Trappole tipiche d’esame

  • Standardizzare molte app senza mantenere Dockerfile → Cloud Native Buildpacks: rilevano il linguaggio e producono l’immagine dal sorgente; il Dockerfile serve solo quando ti occorre controllo fine sui layer o step di build custom.
  • Registro per immagini E pacchetti npm/Maven con scanning → Artifact Registry: Container Registry è legacy e solo container; Artifact Registry aggiunge formati multipli, repo regionali e IAM per repo.
  • Test contro Firestore/Pub/Sub in CI senza costi né risorse reali → emulatori del Cloud SDK: offrono determinismo e isolamento, ma non validano IAM, quote e scala di produzione.
  • Secret nella pipeline → Secret Manager, non in chiaro nel file di Cloud Build: i valori sensibili si iniettano a runtime, mai committati nel repository o nelle env.
  • Cloud Build deve autenticarsi a GCP → service account con least privilege / Workload Identity: evita le service account key esportate, credenziali statiche difficili da ruotare.
  • Rollback affidabile di un deploy → tag immagine con commit SHA: latest è mutabile e non identifica in modo univoco una revisione, rendendo impossibile un rollback deterministico.