Una startup ha spostato un sito di e-commerce ad alto traffico su AWS e ora ha bisogno di CI/CD che notifichi gli ingegneri in caso di build fallite, fornisca deployment senza tempi di inattività e supporti rollback senza interruzioni. Gli sviluppatori utilizzano un repository GitHub privato e Jenkins per le build e i test unitari. Il team utilizzerà AWS CodePipeline per orchestrare build e deployment. Quale design soddisfa i requisiti di notifica, zero downtime e rollback?

L'opzione corretta soddisfa tutti i requisiti. I webhook di GitHub sono il meccanismo standard per attivare CodePipeline in risposta a modifiche nel repository. L'uso del plugin Jenkins per AWS CodeBuild consente di sfruttare l'infrastruttura Jenkins esistente per i test unitari, integrando CodeBuild per scalabilità e gestione. Amazon SNS è il servizio ideale per inviare notifiche affidabili in caso di build fallite. Il deployment blue/green con AWS CodeDeploy è fondamentale per garantire zero downtime e supportare rollback rapidi e senza interruzioni, poiché la nuova versione viene implementata su un ambiente separato prima di reindirizzare il traffico. Le opzioni errate presentano i seguenti difetti: L'uso dei websockets di GitHub non è il metodo standard per l'integrazione con CodePipeline; i webhook sono più appropriati. Il deployment in-place all-at-once non garantisce zero downtime né rollback senza interruzioni. L'uso di AWS X-Ray per i test unitari e l'analisi statica del codice è inappropriato; X-Ray è per il tracciamento delle richieste e l'analisi delle prestazioni, non per i test unitari o l'analisi statica. Anche quest'ultima opzione presenta l'errore di usare AWS X-Ray per i test unitari e l'analisi statica del codice, e il deployment in-place all-at-once non soddisfa i requisiti di zero downtime e rollback.