Amazon DVA-C02: Distribuzione e CI/CD (CodePipeline, CodeBuild, CodeDeploy, Elastic Beanstalk, Containers) — Guida allo studio

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Fa parte della AWS Developer Associate DVA-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Fondamenti di CI/CD con CodePipeline e CodeBuild: pattern, API e insidie comuni

Progetta pipeline con fasi (stage) chiare: sorgente, build, test, approvazione, deploy e verifica post-deploy. CodePipeline coordina queste fasi; utilizza un ruolo per la pipeline che conceda permessi minimi e mirati e configura ruoli di azione per le integrazioni di terze parti. Attiva le pipeline tramite webhook di CodeCommit o con StartPipelineExecution (AWS SDK: codepipeline.startPipelineExecution) per avvii programmatici. Per i build, prediligi progetti CodeBuild con un file buildspec.yml che definisca le fasi (install, pre_build, build, post_build); invoca i build direttamente con StartBuild o StartBuildBatch quando necessiti di build ad-hoc o batch. Per la creazione di immagini, usa aws ecr get-login-password con un pipe verso docker login nella fase di pre_build, poi esegui docker build/push su ECR e cattura il digest dell’immagine per produrre riferimenti immutabili agli artefatti. Evita di usare tag flottanti come “latest”; emetti invece definizioni di task o file manifest che facciano riferimento ai digest delle immagini, in modo che i deployment siano deterministici. Fai attenzione alle insidie comuni: token di autenticazione ECR scaduti in script di lunga durata, policy IAM di CodeBuild inadeguate per il push su ECR o per chiamare API AWS, e codifica statica (hard-coding) degli ARN. Strumenta i build per caricare gli artefatti su S3 o sull’artifact store della pipeline, e usa variabili d’ambiente e Parameter Store/Secrets Manager per valori sensibili e necessari solo a runtime, invece di incorporare segreti negli artefatti di build.

Strategie di deployment: CodeDeploy, alias di Lambda e scelte di configurazione di Elastic Beanstalk

Scegli il modello di deployment che corrisponde alla tolleranza al rischio e alle necessità di rollback. Per Lambda, usa versioni e alias; pubblica una versione (lambda.publishVersion) e aggiorna gli alias con regole di traffic-shifting tramite CodeDeploy, creando un deployment (codedeploy.createDeployment) che faccia riferimento all’applicazione Lambda e al gruppo di deployment. Usa configurazioni predefinite di CodeDeploy come CodeDeployDefault.LambdaCanary10Percent5Minutes o un instradamento del traffico personalizzato per spostamenti canary o lineari precisi. Per applicazioni su EC2 e on-premise, CodeDeploy supporta il blue/green con hook del ciclo di vita per validazioni pre-traffico e rollback automatico in caso di fallimento degli health check. Elastic Beanstalk offre diverse policy: All at Once (veloce, rischioso), Rolling, Rolling with Additional Batch (più sicuro) e Immutable (il più sicuro), e puoi modificarle con eb deploy o tramite l’API update-environment specificando DeploymentPolicy e OptionSettings. Trappole comuni per gli sviluppatori includono dimenticare di configurare gli health check dell’applicazione (integrità del target group dell’ALB, reporting di salute di EB), il che impedisce il passaggio automatico del traffico, e permessi IAM insufficienti affinché CodeDeploy possa invocare Lambda o aggiornare ECS. Per i rilasci che coinvolgono un database, considera modifiche allo schema retrocompatibili e feature toggle pre-deploy per evitare di accoppiare codice e schema nella stessa transazione.

Pipeline per container, ECR, ECS/Fargate ed EKS: build, deploy e riferimenti immutabili

Una pipeline robusta per container crea immagini in CodeBuild, le pusha su ECR e innesca il deployment su ECS, Fargate o EKS. In CodeBuild, esegui aws ecr get-login-password | docker login –username AWS –password-stdin ${ACCOUNT}.dkr.ecr.${REGION}.amazonaws.com, poi docker build -t repo:tag ., docker push, e cattura il digest dell’immagine tramite docker inspect –format=’{{index .RepoDigests 0}}’ image. Per ECS/Fargate, registra la nuova definizione di task (ecs.registerTaskDefinition) con il digest dell’immagine in containerDefinitions, poi aggiorna il servizio (ecs.updateService) per usare la nuova definizione di task o imposta forceNewDeployment per innescare la sostituzione; usa CodeDeploy per deployment blue/green su ECS con traffic shifting a livello di ALB. Per EKS, aggiorna i manifest di Kubernetes per fare riferimento ai digest delle immagini e applica kubectl set image o usa strumenti GitOps dichiarativi; CodeBuild può eseguire i comandi aws eks update-kubeconfig e kubectl. Errori tipici: usare tag mutabili che causano deploy non aggiornati, non aggiornare le definizioni di task impedendo a ECS di deployare nuove immagini, limiti insufficienti di CPU/memoria o ENI sui task Fargate, e dimenticare di concedere a CodeBuild il permesso ecr:BatchGetImage per leggere le immagini pushate.

Validazione pre-deployment, rollback e osservabilità: test, hook e misure di sicurezza operative

Integrare test automatici unitari, di integrazione e di smoke nelle fasi della pipeline. Utilizzare CodeBuild per eseguire i test e AWS X-Ray o CloudWatch Logs per il tracciamento e i log strutturati; annotare le tracce di X-Ray con PutAnnotation negli SDK in modo che le query successive possano filtrare per utente o attributi della richiesta. Per il pre-deployment, impiegare azioni di approvazione manuale in CodePipeline o passaggi di validazione automatizzati: eseguire controlli Canary tramite CodeBuild che sollecitano l’endpoint distribuito, o invocare i canary di CloudWatch Synthetics per eseguire verifiche tramite script. Utilizzare gli hook del ciclo di vita di CodeDeploy (BeforeAllowTraffic, AfterAllowTraffic) per eseguire controlli di integrità (health check) e logiche di registrazione/deregistrazione. Implementare trigger di rollback automatico: configurare CodeDeploy per eseguire il rollback in caso di stato di deployment diverso da zero o di allarmi falliti (allarmi CloudWatch associati al gruppo di deployment), e per Lambda utilizzare gli alias con spostamento del traffico (traffic shifting) per consentire un rollback rapido aggiornando l’alias affinché punti alla versione precedente. Le trappole per sviluppatori includono timeout non corrispondenti (timeout di Lambda più breve del visibility timeout di SQS), dimenticare di impostare correttamente gli hook AppSpec per ECS/CodeDeploy e fare affidamento sul successo delle chiamate API di deployment senza convalidare il comportamento a runtime. Strumentare i deployment con metriche e allarmi, e utilizzare identificatori immutabili negli artefatti per la tracciabilità.

Problema Pratico: Scenario d’Uso

Scenario: ExampleRetail gestisce uno storefront a microservizi in AWS su account di sviluppo/test/produzione. Utilizzano CodeCommit per il codice sorgente, CodePipeline/CodeBuild per la CI, ECR per le immagini, ECS/Fargate per i servizi dietro un ALB e Lambda per i worker asincroni.

Sfida: Uno sviluppatore deve aggiungere una pipeline sicura e automatizzata per distribuire un nuovo container del servizio di checkout con spostamento del traffico di tipo canary e validazione pre-deployment automatizzata che eseguirà il rollback in caso di fallimento.

Approccio Consigliato:

1. Creare un progetto CodeBuild che costruisca l’immagine Docker, esegua i test unitari, effettui il login a ECR (aws ecr get-login-password | docker login –username AWS –password-stdin ${ACCOUNT}.dkr.ecr.${REGION}.amazonaws.com), pubblichi (push) l’immagine ed emetta un artefatto JSON contenente il digest dell’immagine.
2. In CodePipeline, aggiungere una fase di deploy che registri una nuova definizione di task ECS tramite ecs.registerTaskDefinition facendo riferimento al digest dell’immagine, quindi crei un deployment ECS di CodeDeploy chiamando codedeploy.createDeployment con un AppSpec che associa la nuova definizione di task e un deploymentConfig impostato per canary (es. CodeDeployDefault.ECSCanary10Percent5Minutes).
3. Aggiungere un’azione di validazione basata su CodeBuild o un canary di CloudWatch Synthetics come test post-deployment che chiami gli endpoint critici del checkout e ne convalidi le risposte; fare in modo che la pipeline attenda il successo della validazione.
4. Configurare le opzioni di rollback di CodeDeploy e un allarme CloudWatch legato al gruppo di deployment (es. tasso di errori 5xx o latenza) per interrompere ed eseguire il rollback automaticamente se le soglie vengono superate.

Motivazione: Costruire immagini immutabili, registrare definizioni di task con digest di immagine espliciti e utilizzare lo spostamento del traffico (traffic-shifting) di CodeDeploy insieme alla validazione automatizzata fornisce rilasci canary sicuri e rollback rapidi e automatici, garantendo al contempo che i deployment siano riproducibili e osservabili.

← CloudFormation e Infrastruttura come Codice (SAM · Tutti i domini · Sicurezza →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Amazon →