L'azienda ha molte applicazioni create con linguaggi e framework diversi, in esecuzione on-premises su vari sistemi operativi. Ogni team ha il proprio processo di rilascio. L'azienda desidera un controllo centralizzato del codice sorgente, una pipeline di delivery automatizzata coerente e una manutenzione minima dell'infrastruttura dopo la migrazione ad AWS. Quale approccio soddisfa questi obiettivi?

L'approccio corretto soddisfa tutti i requisiti. L'uso di un repository CodeCommit separato per ogni applicazione garantisce un controllo del codice sorgente centralizzato e isolato. La creazione di immagini Docker con CodeBuild e l'archiviazione in ECR standardizza il processo di compilazione e pacchettizzazione per linguaggi e framework diversi. La distribuzione su ECS con Fargate, gestita da CodeDeploy, fornisce una pipeline di delivery automatizzata e coerente, riducendo al minimo la manutenzione dell'infrastruttura grazie alla natura serverless di Fargate. Le opzioni errate presentano dei limiti: La prima opzione, con un unico repository e branch per tutte le applicazioni, rende la gestione del codice sorgente complessa e rischiosa, e la distribuzione su un server applicativo centralizzato non è scalabile né resiliente. La seconda opzione, pur utilizzando repository separati, mantiene la distribuzione su un server applicativo centralizzato, che non è l'ideale per la scalabilità e la manutenzione minima. La terza opzione, che crea AMI per ogni server e utilizza CloudFormation StackSets, introduce una maggiore complessità nella gestione delle AMI e dell'infrastruttura sottostante rispetto a un approccio containerizzato con Fargate.