Qual è la differenza tra Continuous Delivery e Continuous Deployment?
Entrambe si basano sulla Continuous Integration e mantengono ogni modifica che passa la pipeline in stato rilasciabile, ma differiscono nello step finale. La Continuous Delivery automatizza tutto fino alla produzione e lascia il rilascio come decisione di business manuale, a un clic, quindi è un essere umano a scegliere quando spedire. La Continuous Deployment rimuove del tutto quel gate: ogni modifica che passa l'intera pipeline va in produzione automaticamente, il che richiede una suite di test ad alta confidenza, rollout progressivo e rollback automatico rapido, perché nessun umano revisiona il rilascio.
Quanto piccoli dovrebbero essere i miei commit e le pull request perché la CI funzioni bene?
Abbastanza piccoli da integrarsi almeno una volta al giorno, idealmente molte volte al giorno. La Continuous Integration porta il suo beneficio - intercettare conflitti e rotture in pochi minuti - solo quando le modifiche vengono unite di continuo in un mainline condiviso, motivo per cui il trunk-based development preferisce commit minuscoli dietro feature flag ai branch longevi. Branch grandi e di lunga durata reintroducono il doloroso merge di fine ciclo che la CI esiste per eliminare, quindi la regola pratica è spezzare il lavoro nella più piccola modifica che mantiene la build verde.
Quando scegliere blue-green invece di canary?
Scegli blue-green quando vuoi il rollback istantaneo più semplice possibile e puoi permetterti di eseguire due ambienti completi durante il cutover, poiché ricommutare il traffico verso l'ambiente vecchio è immediato. Scegli canary quando vuoi limitare il blast radius di un rilascio difettoso esponendolo prima a una piccola frazione di traffico e osservando metriche reali prima di allargare, cosa che intercetta problemi che la commutazione "tutto in una volta" del blue-green non coglierebbe. Il canary richiede buona observability e un livello di traffic-splitting; il blue-green richiede circa il doppio dell'infrastruttura per la durata della commutazione.
Perché gli artefatti di build dovrebbero essere immutabili e costruiti una sola volta?
Costruire una volta e promuovere lo stesso artefatto attraverso ogni ambiente garantisce che i byte testati in staging siano esattamente i byte eseguiti in produzione, eliminando un'intera classe di difetti "funzionava in staging" causati da ricompilazioni che raccolgono dipendenze diverse. Se ogni ambiente ricompila dal sorgente, differenze sottili nella versione della toolchain, nella risoluzione delle dipendenze transitive o nel timing della build possono cambiare il comportamento. La disciplina è produrre un artefatto versionato e immutabile nella CI e far sì che la CD distribuisca quell'esatto artefatto, riferito per digest del contenuto, ovunque a valle.
Quali sono le quattro DORA metrics e perché contano?
Le quattro DORA metrics sono deployment frequency e lead time for changes, che misurano il throughput, e change failure rate e mean time to recovery, che misurano la stabilità. Contano perché anni di ricerca mostrano che i team di elite ottengono buoni risultati su tutte e quattro contemporaneamente, smentendo la convinzione che si debba sacrificare la velocità per la stabilità. Offrono a un team un metro oggettivo e supportato dalla ricerca per capire se i cambiamenti di processo stanno davvero migliorando la delivery anziché solo dare la sensazione di andare più veloci.
Come tengo i segreti fuori dalla mia pipeline CI/CD e dalla cronologia Git?
Non committare mai segreti nel repository; conservali in un secrets manager dedicato (HashiCorp Vault, AWS Secrets Manager o lo store crittografato del tuo provider CI) e iniettali nella pipeline a runtime come variabili d'ambiente mascherate. Aggiungi il secret-scanning agli hook pre-commit e alla CI così che un commit accidentale venga intercettato prima del merge, e tratta qualsiasi segreto che ha toccato la cronologia Git o un log di build come compromesso, ruotandolo immediatamente. Preferisci credenziali a vita breve e ruotate automaticamente e la federazione basata su OIDC alle chiavi statiche di lunga durata, così che una fuga abbia una finestra di utilità ridotta.
Cos'è il GitOps e in cosa differisce da una normale pipeline CD?
Il GitOps fa di Git l'unica fonte di verità per lo stato desiderato di infrastruttura e applicazioni, con un agent in-cluster (Argo CD o Flux) che tira di continuo quello stato e riconcilia il sistema live affinché corrisponda. La differenza chiave rispetto a una pipeline push tradizionale è la direzione e la gestione del drift: invece che la CI spinga le modifiche nel cluster, il cluster tira da Git, e qualsiasi drift manuale viene rilevato e corretto automaticamente verso lo stato dichiarato. Questo dà una traccia di audit completa nella cronologia Git, un rollback facile revertendo un commit e un sistema self-healing.
Come ottengo deploy a downtime zero?
Porta su le nuove istanze e conferma che superino i readiness check prima di drenare e rimuovere quelle vecchie, usando una strategia rolling update, blue-green o canary dietro un load balancer che rispetta il connection draining. La metà più difficile è il database: le modifiche di schema devono essere retrocompatibili così che vecchia e nuova versione applicativa possano coesistere durante il passaggio, motivo per cui il pattern expand-then-contract (aggiungi la nuova colonna, distribuisci codice che scrive su entrambe, fai il backfill, e solo più tardi rimuovi la vecchia colonna) è l'approccio standard. Readiness e liveness probe accurate sono ciò che permette alla piattaforma di prendere decisioni di traffico sicure in automatico.
Cosa dovrebbe contenere un buon endpoint di health check?
Un health check dovrebbe riportare se l'istanza può effettivamente servire traffico, non semplicemente che il processo è in esecuzione. Kubernetes distingue una liveness probe, che riavvia un processo bloccato, da una readiness probe, che rimuove un'istanza dal load balancing finché le sue dipendenze critiche (pool di connessioni al database, cache richieste) non sono raggiungibili, e una startup probe, che concede tempo alle app dall'avvio lento prima che la liveness entri in azione. Un errore comune è far dipendere la readiness da un servizio downstream non critico, il che causa outage a cascata quando quella dipendenza ha un'intermittenza, quindi limita ogni probe a ciò che determina davvero la servibilità.
Come rendo sicure le migrazioni di database in una pipeline CI/CD?
Applica le migrazioni come uno step discreto, versionato e idempotente (Flyway, Liquibase o il migrator del tuo ORM) e progetta ogni modifica perché sia retrocompatibile così da poterla distribuire prima del codice che la richiede e revertirla senza perdita di dati. Segui il pattern expand-then-contract: le modifiche additive (nuove colonne nullable, nuove tabelle) vanno per prime e sono sicure da revertire, mentre le modifiche distruttive (eliminare una colonna) avvengono solo dopo che nessun codice in esecuzione la referenzia più. Esegui le migrazioni solo in avanti in produzione e testale rispetto a un dataset simile a quello di produzione nella pipeline, perché una migrazione che blocca una tabella grande può causare un outage anche quando l'SQL è corretto.
Cosa significa "shift left" e cosa dovrei spostare prima?
Fare shift left significa eseguire i controlli di qualità e sicurezza il più presto possibile - sulla macchina dello sviluppatore e nella pull request - anziché scoprire i problemi tardi in un rilascio. In pratica, sposta linting, unit test, scansione delle vulnerabilità delle dipendenze, rilevamento dei segreti e scansione dell'IaC negli hook pre-commit e nella pipeline della PR così che i difetti siano intercettati quando costano meno da correggere e l'autore ha ancora pieno contesto. L'obiettivo è il feedback rapido: uno sviluppatore che scopre una dipendenza vulnerabile nella sua PR la corregge in pochi minuti, mentre lo stesso rilievo in un audit trimestrale costa molto di più.
Le definizioni delle pipeline dovrebbero vivere nel repository?
Sì. I file di pipeline-as-code come .github/workflows/ci.yml, .gitlab-ci.yml o un Jenkinsfile dovrebbero essere versionati insieme al codice applicativo che costruiscono, così che la pipeline evolva con il codice, le modifiche passino dalla review e si possa riprodurre esattamente come è stato costruito e testato qualsiasi commit passato. Tenere la logica della pipeline in una UI o in una configurazione out-of-band la rende invisibile, non revisionabile e impossibile da revertire insieme al codice. Trattare la pipeline come codice permette anche di riusarla e testarla come qualsiasi altro software.
Quanto grande dovrebbe essere un'immagine container e come la riduco?
Più piccola è meglio per tempo di pull, superficie d'attacco e densità, quindi punta a spedire solo il runtime e l'applicazione, non la toolchain di build. La tecnica principale è una multi-stage build che compila in uno stage e copia solo l'artefatto finito in uno stage finale minimale basato su un'immagine snella o distroless. Ordina le istruzioni del Dockerfile dal meno al più frequentemente modificato per massimizzare il riuso della layer cache, evita di installare pacchetti non necessari e non incorporare mai segreti in un layer, perché i layer sono estraibili singolarmente.
Qual è la differenza tra observability e monitoring?
Il monitoring raccoglie e allerta su un insieme predefinito di segnali per rilevare modi di fallimento noti - "la CPU è alta, l'error rate è sopra soglia?" - ed è essenziale ma limitato a ciò che hai pensato di osservare. L'observability è la proprietà più ampia di poter porre nuove domande sul comportamento del sistema dai suoi output (metriche, log e tracce) senza rilasciare nuovo codice, che è ciò che serve per diagnosticare problemi nuovi e imprevisti. In pratica si costruisce il monitoring sopra sistemi osservabili: una strumentazione ricca abilita sia le dashboard predefinite sia l'indagine ad-hoc che non avevi previsto.
Come faccio un rollback di un rilascio in modo rapido e sicuro?
Il rollback più veloce è quello pianificato: distribuisci artefatti immutabili e versionati così che revertire significhi ridistribuire la versione precedente nota come buona, e preferisci strategie con rollback integrato come il blue-green (ricommuta il traffico) o il GitOps (reverti il commit). La complicazione è sempre lo stato - un rilascio che ha eseguito una migrazione di database incompatibile non può semplicemente revertire il codice - motivo per cui le migrazioni retrocompatibili expand-then-contract sono un prerequisito per un rollback sicuro. Prova i rollback così che siano routine anziché un'emergenza improvvisata, e collega il rollback automatico ai tuoi smoke test e alle metriche del canary.
Come metto in sicurezza la mia software supply chain nella pipeline?
Tratta tutto ciò che entra in una build come non fidato finché non è verificato: pinna le dipendenze per hash, scansionale per CVE note e problemi di licenza a ogni build (Software Composition Analysis), e genera una Software Bill of Materials così da poter rispondere "siamo colpiti?" in pochi minuti quando arriva il prossimo Log4Shell. Firma i tuoi artefatti di build (Sigstore/cosign) e produci una provenienza della build verificabile secondo il framework SLSA così che i consumatori possano provare che l'artefatto proviene dalla tua pipeline e non è stato manomesso. Blinda l'ambiente di build stesso con credenziali a privilegio minimo e runner effimeri, perché il sistema di build è un bersaglio di alto valore.