Utilizzi Cloud Run e Cloud Source Repositories e disponi di un file YAML di Cloud Build che crea il container ed esegue gcloud run deploy. Quale passaggio successivo rende i deployment più efficienti?

La risposta corretta è "Crea un trigger di build che esegue il file di build in risposta al push di codice del repository sul ramo di sviluppo." Questo approccio automatizza il processo di deployment in modo efficiente. Cloud Build può essere configurato per monitorare un repository Cloud Source e avviare una build (e quindi un deployment) ogni volta che viene eseguito un push su un ramo specifico (ad esempio, il ramo di sviluppo). Questo garantisce che ogni modifica al codice venga automaticamente testata e deployata, riducendo gli errori manuali e accelerando il ciclo di sviluppo. Le altre opzioni sono meno efficienti o appropriate: Creare un argomento Pub/Sub e un trigger Pub/Sub è un approccio più complesso e meno diretto per reagire ai push del repository rispetto a un trigger di Cloud Build nativo. Un trigger di build webhook richiede una configurazione esterna per inviare le chiamate HTTP POST, rendendolo meno integrato e più macchinoso rispetto a un trigger basato sul repository. Un processo Cron che esegue gcloud builds submit ogni 24 ore non è efficiente perché non reagisce immediatamente ai cambiamenti del codice e potrebbe deployare versioni obsolete o non deployare affatto per un lungo periodo.