Artifact (artefatto di build)
Un artefatto di build è l'output impacchettato e immutabile di uno step di build - un'immagine container, un JAR, una wheel, uno zip o un binario firmato - che le fasi successive della pipeline distribuiscono senza ricompilare. Gli artefatti sono versionati e conservati in un registry (registry OCI, npm, Maven, PyPI) così che i bit testati siano esattamente i bit rilasciati. Trattare l'artefatto come immutabile è ciò che rende possibile il principio "build once, deploy many".
Artifact Registry
Un artifact registry è un archivio versionato per gli output di build come immagini container, pacchetti di linguaggio e chart Helm, indirizzati per nome e tag oppure per digest del contenuto. Esempi sono Docker Hub, GitHub Container Registry, Amazon ECR e JFrog Artifactory. Effettuare il pull per digest immutabile invece che per tag mutabile garantisce che i byte distribuiti coincidano con quelli testati.
Blue-Green Deployment
Il blue-green deployment mantiene due ambienti di produzione identici, "blue" (live) e "green" (inattivo), e sposta il traffico sulla nuova versione commutando un router o un load balancer. Poiché l'ambiente vecchio resta caldo, il rollback è una commutazione di traffico istantanea verso il blue. Il compromesso è circa il doppio dell'infrastruttura durante la finestra di cutover.
Canary Deployment
Un canary deployment rilascia una nuova versione prima a una piccola frazione di traffico o utenti, osserva error rate e latenza rispetto alla baseline, poi sposta progressivamente più traffico se i segnali restano sani. Limita il blast radius di un rilascio difettoso e consente il rollback automatico in caso di regressione. Richiede buone metriche e un livello di traffic-splitting (service mesh, ingress o feature flag).
CI (Continuous Integration)
La Continuous Integration è la pratica di unire frequentemente il lavoro di ogni sviluppatore in un mainline condiviso - idealmente molte volte al giorno - verificando ogni merge con una build e dei test automatici. Il suo scopo è far emergere conflitti di integrazione e build rotte in pochi minuti anziché in un doloroso merge di fine ciclo. Un mainline verde è il contratto che la CI fa rispettare.
CD (Continuous Delivery)
La Continuous Delivery estende la CI in modo che ogni modifica che supera la pipeline sia sempre in stato distribuibile, rilasciabile in produzione con la pressione di un pulsante. La decisione di rilascio resta manuale, ma la meccanica è completamente automatizzata e collaudata. Non va confusa con la Continuous Deployment, dove anche la pressione del pulsante è automatica.
Continuous Deployment
La Continuous Deployment rilascia automaticamente in produzione ogni modifica che supera l'intera pipeline, senza gate manuale. Richiede una suite di test ad alta confidenza, progressive delivery (canary o blue-green) e rollback automatico rapido, perché non c'è un essere umano nel loop a intercettare una modifica difettosa. È il punto più automatizzato dello spettro CI/CD.
Pipeline
Una pipeline è la sequenza automatica di stage che una modifica attraversa - tipicamente build, test, scan, package e deploy - definita come codice in un file come .github/workflows/ci.yml, .gitlab-ci.yml o un Jenkinsfile. Gli stage girano in ordine, spesso con job paralleli all'interno di uno stage, e un fallimento interrompe il resto. La definizione della pipeline vive nel repository, così è versionata insieme al codice che costruisce.
Stage
Uno stage è una fase logica di una pipeline che raggruppa job correlati, come uno stage di "test" o uno di "deploy", e di solito agisce da gate: lo stage successivo parte solo quando quello corrente ha successo. Gli stage danno alla pipeline la sua forma di alto livello e definiscono dove avvengono approvazioni e fan-out. I job all'interno di uno stage spesso girano in parallelo.
Job
Un job è un'unità di lavoro in una pipeline che gira su un singolo runner o agent, composta da una lista ordinata di step che condividono un workspace e un ambiente. I job all'interno di uno stage possono girare in parallelo; i job tra stage diversi girano in sequenza. Un job fallito tipicamente fa fallire il proprio stage, a meno che non sia esplicitamente autorizzato a fallire.
Runner
Un runner (o agent, o executor) è la macchina o il container che esegue effettivamente un job della pipeline. I runner possono essere ospitati dal provider CI (runner ospitati da GitHub) oppure self-hosted sulla propria infrastruttura per hardware custom, accesso a reti private o controllo dei costi. I runner effimeri, distrutti dopo ogni job, riducono la fuoriuscita di stato tra le build.
Build Cache
Una build cache conserva output di build intermedi e dipendenze scaricate tra le esecuzioni della pipeline, così il lavoro invariato non viene ripetuto, riducendo drasticamente i tempi di build. Le cache sono indicizzate su un hash degli input (lockfile, sorgenti) e devono essere invalidate quando quegli input cambiano. Una cache mal indicizzata che diventa obsoleta è una classica fonte di bug "funziona sulla mia macchina" in pipeline.
GitOps
Il GitOps è un modello operativo in cui lo stato desiderato di infrastruttura e applicazioni è dichiarato in Git, e un agent in-cluster (come Argo CD o Flux) riconcilia continuamente il sistema live affinché corrisponda. Git diventa l'unica fonte di verità e il log di audit; i deploy avvengono mergendo un commit, e la deriva (drift) viene rilevata e corretta automaticamente. Si sposa naturalmente con Kubernetes e i manifest dichiarativi.
Infrastructure as Code (IaC)
L'Infrastructure as Code gestisce server, reti e risorse cloud tramite file di definizione leggibili dalla macchina (Terraform, Pulumi, CloudFormation, Ansible) tenuti sotto controllo di versione, anziché click manuali in console. Rende gli ambienti riproducibili, revisionabili e ricostruibili, e trasforma le modifiche all'infrastruttura in pull request. La stessa disciplina plan-then-apply usata per il codice vale per l'infrastruttura.
Idempotenza
Un'operazione è idempotente se applicarla più volte produce lo stesso stato finale di applicarla una sola volta. L'idempotenza è centrale per l'apply di IaC, la configuration management e gli script di deploy, perché le riesecuzioni dopo un fallimento parziale devono convergere anziché duplicare risorse. Gli strumenti dichiarativi la ottengono riconciliando verso uno stato desiderato invece di emettere comandi imperativi di creazione.
Configurazione dichiarativa
La configurazione dichiarativa descrive lo stato finale desiderato di un sistema ("devono esserci tre repliche di questo servizio") e lascia a un controller il compito di capire i passi per raggiungerlo, a differenza degli script imperativi che esplicitano ogni comando. È naturalmente idempotente e self-healing perché il controller riconcilia di continuo lo stato reale verso quello desiderato. I manifest Kubernetes e le configurazioni Terraform sono dichiarativi.
Drift
Il configuration drift è la divergenza tra lo stato dichiarato nel codice e lo stato reale del sistema in esecuzione, causato da modifiche manuali, apply falliti o tooling out-of-band. Il drift mina la riproducibilità ed è una causa comune di fallimenti "funzionava in staging". I controller GitOps e terraform plan rilevano il drift; la riconciliazione lo corregge.
Container
Un container è un'unità leggera e isolata che impacchetta un'applicazione con le sue dipendenze e gira come processo su un kernel host condiviso, usando namespace e cgroup per l'isolamento. A differenza di una macchina virtuale non include un intero sistema operativo guest, quindi parte in millisecondi ed è denso da impacchettare. Lo standard OCI definisce i formati di immagine e runtime usati dai container.
Immagine container
Un'immagine container è uno snapshot di filesystem immutabile e a livelli più i metadati (entrypoint, environment, porte esposte) da cui vengono istanziati i container. Le immagini sono costruite da un Dockerfile, identificate da un digest content-addressable e taggate per riferimento umano. Immagini di base più piccole e minimali (distroless, Alpine) riducono superficie d'attacco e tempo di pull.
Dockerfile
Un Dockerfile è la ricetta dichiarativa per costruire un'immagine container, una sequenza di istruzioni (FROM, RUN, COPY, CMD) ciascuna delle quali crea un layer in cache. Ordinare le istruzioni dal meno al più frequentemente modificato massimizza il riuso della layer cache e velocizza le ricompilazioni. Le build multi-stage tengono gli strumenti di build fuori dall'immagine runtime finale.
Multi-Stage Build
Una multi-stage build usa più stage FROM in un unico Dockerfile, compilando o assemblando in uno stage iniziale e copiando solo gli artefatti finiti in uno stage finale snello. Il risultato è un'immagine runtime piccola, priva di compilatori, cache di build e segreti. È la tecnica standard per ridurre dimensione dell'immagine e superficie d'attacco.
Orchestrazione
L'orchestrazione è la pianificazione, lo scaling, il networking e la gestione del ciclo di vita automatici dei container su un cluster di macchine, forniti da sistemi come Kubernetes o Nomad. L'orchestratore colloca i workload, riavvia i container falliti, esegue il rollout di nuove versioni e mantiene il numero di repliche dichiarato. Trasforma una flotta di host in un unico pool di calcolo logico.
Kubernetes
Kubernetes è un orchestratore di container open-source che esegue workload dichiarativi su un cluster, riconciliando lo stato reale verso lo stato desiderato definito nei manifest. Gli oggetti core includono Pod, Deployment, Service e ConfigMap, gestiti dai controller tramite l'API server. È la piattaforma de facto per il deploy cloud-native e il substrato su cui puntano la maggior parte dei tool GitOps e di progressive delivery.
Helm
Helm è un package manager per Kubernetes che raggruppa manifest correlati in un'unità versionata e parametrizzabile chiamata chart, renderizzata con i valori forniti dall'utente al momento dell'installazione. Abilita riuso, templating e rollback dei deploy applicativi. Le release Helm sono tracciate così che helm rollback possa tornare a una revisione precedente.
Rollback
Un rollback riporta un sistema a una versione precedente nota come buona dopo un rilascio difettoso, idealmente come azione rapida, collaudata e automatica anziché come emergenza. Le strategie includono ridistribuire l'artefatto immutabile precedente, ricommutare il traffico nel blue-green o revertire un commit GitOps. Le migrazioni di database complicano il rollback, motivo per cui si preferiscono modifiche di schema retrocompatibili expand-then-contract.
Feature Flag
Un feature flag (toggle) è un interruttore a runtime che attiva o disattiva un percorso di codice senza redeploy, disaccoppiando l'atto di distribuire il codice dall'atto di rilasciare una funzionalità. I flag abilitano dark launch, canary per segmento di utenti e kill switch istantanei per una funzionalità che si comporta male. I flag obsoleti si accumulano come debito tecnico e vanno rimossi una volta completato il rollout.
Trunk-Based Development
Il trunk-based development è un modello di branching in cui gli sviluppatori integrano piccole modifiche in un unico branch condiviso (trunk) almeno una volta al giorno, dietro feature flag quando il lavoro è incompleto. Mantiene i merge minuscoli e continui, ciò che rende possibile la vera CI, ed evita i branch di feature longevi e il merge hell dei flussi più pesanti. Si combina con i feature flag per nascondere il lavoro non finito.
SLI (Service Level Indicator)
Un Service Level Indicator è una misura quantitativa del comportamento di un servizio come percepito dagli utenti, ad esempio latenza delle richieste, error rate o disponibilità. Gli SLI sono i segnali grezzi da cui si fissano gli SLO e si calcolano gli error budget. Un buon SLI è un rapporto tra eventi buoni ed eventi validi che correla con la soddisfazione dell'utente.
SLO (Service Level Objective)
Un Service Level Objective è un valore o intervallo obiettivo per uno SLI su una finestra temporale, ad esempio "il 99,9% delle richieste ha successo in 30 giorni". Gli SLO rendono l'affidabilità un obiettivo ingegneristico misurabile e definiscono quando rallentare il lavoro sulle funzionalità a favore della stabilità. Sono obiettivi interni, tipicamente più stringenti di qualsiasi SLA promesso all'esterno.
Error Budget
Un error budget è la quantità di inaffidabilità che uno SLO consente - il complemento dell'obiettivo, quindi uno SLO di disponibilità del 99,9% consente lo 0,1% di errori. Finché il budget non è esaurito, il team può rilasciare in modo aggressivo; una volta esaurito, la policy sposta la priorità sul lavoro di affidabilità. Trasforma la tensione tra velocità e stabilità in un numero oggettivo.
Observability
L'observability è la proprietà di un sistema che permette di comprenderne lo stato interno dai suoi output esterni, classicamente tramite metriche, log e tracce (i "tre pilastri"). A differenza del monitoring di base sui modi di fallimento noti, l'observability mira a permettere di porre nuove domande su problemi imprevisti senza rilasciare nuovo codice. È il prerequisito per una progressive delivery sicura e per una diagnosi rapida degli incidenti.
Monitoring
Il monitoring è la raccolta continua e l'allerta su segnali predefiniti - CPU, memoria, request rate, error rate - per rilevare condizioni di fallimento note. Risponde alla domanda "il sistema è sano rispetto alle cose che già sappiamo di osservare?", mentre l'observability si estende all'indagine degli ignoti. Prometheus e Grafana sono uno stack di monitoring open-source comune.
Metriche
Le metriche sono misurazioni numeriche campionate nel tempo, come counter, gauge e istogrammi, economiche da archiviare e ideali per dashboard, trend e alerting. Aggregano bene ma perdono il dettaglio per singola richiesta, motivo per cui si abbinano a tracce e log. Il metodo RED (Rate, Errors, Duration) e il metodo USE (Utilization, Saturation, Errors) sono framework di metriche comuni.
Distributed Tracing
Il distributed tracing segue una singola richiesta mentre si propaga attraverso i servizi, registrando span temporizzati collegati da un trace ID condiviso per rivelare dove si accumulano latenza ed errori. È essenziale per il debug dei microservizi, dove una singola azione utente si dirama verso molti backend. OpenTelemetry è lo standard vendor-neutral per strumentare tracce, metriche e log.
Secrets Management
Il secrets management è l'archiviazione, distribuzione, rotazione e auditing sicuri di credenziali come chiavi API, token e password di database, usando un sistema dedicato (HashiCorp Vault, AWS Secrets Manager, sealed secrets) invece di testo in chiaro nel codice o nei file di environment. I segreti vanno iniettati a runtime, mai committati in Git, e ruotati regolarmente. Un segreto trapelato nei log di pipeline è un incidente frequente ed evitabile.
Shift Left
Fare shift left significa spostare le attività di qualità e sicurezza - testing, linting, scansione delle dipendenze, rilevamento dei segreti - più presto nel ciclo di sviluppo, idealmente sulla macchina dello sviluppatore e nella pull request, anziché tardi in un rilascio. Intercettare i difetti prima è enormemente più economico che intercettarli in produzione. È un principio guida del DevSecOps.
DevSecOps
Il DevSecOps integra le pratiche di sicurezza nella pipeline DevOps, così che la sicurezza sia una responsabilità condivisa, automatizzata e continua anziché un gate alla fine. Incorpora SAST, DAST, scansione delle dipendenze, scansione dell'IaC e controlli di policy nel CI/CD. L'obiettivo è rendere il percorso sicuro il percorso facile e di default per gli sviluppatori.
SAST (Static Application Security Testing)
Lo Static Application Security Testing analizza codice sorgente o binari senza eseguirli per trovare pattern di vulnerabilità come difetti di injection, deserializzazione insicura e segreti hardcoded. Gira presto (nell'IDE o su ogni pull request) e scala a ogni commit, ma produce falsi positivi e non può trovare problemi solo a runtime. Complementa il DAST, che testa l'applicazione in esecuzione.
DAST (Dynamic Application Security Testing)
Il Dynamic Application Security Testing sonda un'applicazione in esecuzione dall'esterno, inviando input creati ad arte per trovare vulnerabilità che emergono solo a runtime, come difetti di autenticazione e misconfigurazioni del server. Ha pochi falsi positivi ma gira più tardi e copre solo i percorsi esercitati. Complementa il SAST, che ispeziona il codice staticamente.
SBOM (Software Bill of Materials)
Una Software Bill of Materials è un inventario formale e leggibile dalla macchina di ogni componente e dipendenza di un software, incluse versioni e licenze, espresso in un formato standard come SPDX o CycloneDX. Permette una valutazione d'impatto rapida quando emerge una vulnerabilità come Log4Shell, e sostiene la sicurezza della supply chain e la compliance. Generare una SBOM per ogni build è sempre più richiesto dalla normativa.
Supply Chain Security
La sicurezza della software supply chain protegge l'integrità di tutto ciò che confluisce in un rilascio - dipendenze, sistemi di build e artefatti - contro manomissioni, typosquatting e toolchain compromesse. Le pratiche includono il pinning delle dipendenze per hash, la generazione di SBOM, la firma degli artefatti (Sigstore/cosign) e l'attestazione della provenienza della build (SLSA). Gli incidenti xz e SolarWinds l'hanno resa una preoccupazione a livello di consiglio di amministrazione.
DORA Metrics
Le DORA metrics sono quattro misure della performance di delivery del software, supportate dalla ricerca, provenienti dal programma DevOps Research and Assessment: deployment frequency, lead time for changes, change failure rate e time to restore service. Le prime due misurano il throughput; le ultime due la stabilità, e i team di elite eccellono in entrambe contemporaneamente. Sono il metro standard per valutare la capacità DevOps.
Lead Time for Changes
Il lead time for changes, una delle quattro DORA metrics, misura il tempo dal commit di una modifica al codice fino alla sua esecuzione in produzione. Un lead time breve riflette una pipeline veloce, automatizzata e a basso attrito e batch di piccole dimensioni. È una metrica di throughput, abbinata alla deployment frequency e bilanciata rispetto alle metriche di stabilità.
Mean Time to Recovery (MTTR)
Il Mean Time to Recovery (o Restore) misura quanto tempo serve per ripristinare il servizio dopo un guasto in produzione. Un MTTR basso - reso possibile da buona observability, rollback rapido e risposta agli incidenti collaudata - conta più, per l'affidabilità percepita dall'utente, che cercare di non fallire mai. È una delle due metriche di stabilità DORA, insieme al change failure rate.
Change Failure Rate
Il change failure rate, una metrica di stabilità DORA, è la proporzione di deploy in produzione che causano un guasto che richiede rimedi come rollback, hotfix o patch. Più è basso, meglio è; i team di elite lo mantengono basso pur effettuando deploy frequenti, dimostrando che velocità e stabilità non sono in opposizione. Si legge insieme all'MTTR per giudicare la sicurezza dei rilasci.
Immutable Infrastructure
L'immutable infrastructure tratta server e immagini come mai modificati sul posto: per cambiare un sistema in esecuzione si costruisce una nuova immagine e si sostituiscono le istanze anziché applicare patch agli host live. Questo elimina il configuration drift e gli "snowflake server", e rende il rollback un redeploy dell'immagine precedente. È abilitata da IaC e immagini container ed è alla base di deploy affidabili e ripetibili.
Smoke Test
Uno smoke test è una suite piccola e veloce che verifica che i percorsi più critici di una build appena distribuita funzionino - il servizio parte, risponde agli health check e serve un endpoint chiave - prima di promuoverla oltre. È il rapido controllo "va a fuoco?" dopo un deploy, distinto dal testing di regressione completo. Smoke test falliti dovrebbero fermare o revertire automaticamente un rollout.
Health Check
Un health check è un endpoint o una probe che la piattaforma interroga per decidere se un'istanza è viva e pronta a ricevere traffico. Kubernetes distingue una liveness probe (riavvia se non sana) da una readiness probe (rimuove dal load balancing finché non è pronta) e una startup probe (concede tempo ai boot lenti). Health check accurati sono essenziali per i deploy a downtime zero e per il self-healing.
Zero-Downtime Deployment
Un deploy a downtime zero rilascia una nuova versione senza interrompere il servizio, portando su le nuove istanze e drenando quelle vecchie solo dopo che sono sane e in servizio. Le tecniche includono rolling update, blue-green e canary, tutte basate su readiness check accurati e connection draining. Sono richieste modifiche di database retrocompatibili affinché vecchia e nuova versione possano coesistere durante il passaggio.