Il flusso CI/CD e AWS CodePipeline
La CI/CD automatizza il percorso dal commit al rilascio, eliminando i passaggi manuali che introducono errori. Su AWS l’orchestratore è AWS CodePipeline: un modello a stage sequenziali (tipicamente source, build, test, deploy), dove ogni stage contiene una o più action. Gli artefatti prodotti da uno stage vengono passati al successivo tramite un artifact store su Amazon S3.
Il source stage può leggere da CodeCommit, da un bucket S3, da una immagine su Amazon ECR oppure da GitHub tramite una connection. Un punto d’esame ricorrente: CodePipeline reagisce agli eventi (change detection via Amazon EventBridge) e non fa polling continuo se configurato correttamente. Le transition tra stage possono essere disabilitate per bloccare temporaneamente il flusso, mentre un fallimento in uno stage arresta la progressione verso quelli a valle.
CodeBuild, buildspec e il test gate
AWS CodeBuild è il servizio di build fully managed. La sua logica vive nel file buildspec.yml, organizzato in fasi: install, pre_build, build, post_build, più sezioni per env, artifacts, cache e reports. Ogni comando che ritorna un exit code diverso da zero fa fallire la fase, e un fallimento nella fase di test blocca l’intera pipeline: è così che si costruisce un test gate. I risultati dei test possono essere pubblicati come test report per l’analisi dei trend.
CodeBuild è anche il punto naturale per costruire immagini container e fare il push su Amazon ECR. Il build role deve avere i permessi ECR (tra cui l’autorizzazione al registro e la pubblicazione dei layer), l’ambiente deve girare in privileged mode per usare il Docker daemon, e occorre autenticarsi al registry ottenendo un token temporaneo. I segreti (credenziali, chiavi) vanno letti da AWS Secrets Manager o Parameter Store, mai messi in chiaro nel buildspec.
AWS CodeDeploy e le strategie di rilascio
AWS CodeDeploy gestisce il rilascio applicativo su tre compute platform: EC2/on-premises, AWS Lambda e Amazon ECS. Il comportamento è descritto dal file appspec e dai suoi lifecycle hook.
Le strategie cambiano con la piattaforma:
- Su EC2/on-premises si sceglie fra in-place (aggiorna le istanze esistenti) e blue/green (crea un nuovo set e sposta il traffico), con deployment config come AllAtOnce, HalfAtATime, OneAtATime.
- Su Lambda ed ECS il rilascio è sempre blue/green con traffic shifting: canary (una piccola percentuale, poi il resto dopo un intervallo) o linear (incrementi costanti a intervalli regolari), oppure AllAtOnce.
Il valore chiave è il rollback automatico: se un CloudWatch alarm scatta durante lo shift o gli hook di validazione falliscono, CodeDeploy riporta il traffico alla versione precedente. Blue/green e canary riducono il blast radius di un rilascio difettoso, al prezzo di più risorse temporanee.
Approvazioni manuali e controllo del flusso
L’action di tipo manual approval inserisce un gate umano in CodePipeline: la pipeline si mette in pausa finché un utente con i permessi non approva o rifiuta, e può inviare una notifica via Amazon SNS con un link di revisione. È lo strumento tipico prima di un deploy in produzione, per separare CI automatica e CD controllata. Un’approvazione non produce artefatti: serve solo come cancello decisionale.
Trappole tipiche d’esame
- Un test deve bloccare il rilascio → soluzione: far ritornare al comando di test un exit code diverso da zero nel buildspec; CodeBuild fallisce la fase e CodePipeline arresta gli stage successivi. Non serve logica custom di stop.
- Serve un’approvazione umana prima della produzione → soluzione: una manual approval action in CodePipeline con notifica SNS; non è un compito di CodeDeploy né di CodeBuild.
- Rilascio Lambda/ECS che deve limitare il rischio → soluzione: CodeDeploy con canary o linear e rollback su CloudWatch alarm; l’in-place con AllAtOnce esiste solo per EC2 e massimizza il blast radius.
- Build che pusha su ECR ma fallisce l’autenticazione → soluzione: al build role mancano i permessi ECR o l’ambiente non è in privileged mode; il token del registry è temporaneo e va rigenerato a ogni build.
- CodePipeline che sembra lento a partire dopo un commit → soluzione: affidarsi al change detection via EventBridge invece del polling periodico, che introduce latenza.
- Segreti nel buildspec → soluzione: referenziare Secrets Manager o Parameter Store dalla sezione env, mai scrivere credenziali in chiaro nel file versionato.