Executive summary
Quando un'organizzazione sviluppa software e deve rilasciare aggiornamenti in modo frequente e affidabile, il processo che collega la scrittura del codice alla sua messa in esercizio diventa un fattore critico di competitività. Questo articolo analizza le architetture e le strategie che governano tale processo, esaminando come le diverse soluzioni disponibili affrontino il problema della velocità di rilascio senza sacrificare la qualità e la sicurezza del software prodotto. Dall'analisi emerge che le organizzazioni con i risultati migliori adottano un insieme coordinato di pratiche che comprende integrazioni frequenti sul ramo principale di sviluppo, automazione stratificata dei controlli di qualità e meccanismi di sincronizzazione continua tra lo stato descritto nei sistemi di gestione del codice e quello effettivamente in esercizio. L'indagine evidenzia inoltre che la sicurezza della catena di produzione del software rappresenta una frontiera in rapida evoluzione, con standard emergenti che definiscono livelli progressivi di garanzia sull'integrità di ciò che viene rilasciato.
Background
Il concetto di continuous integration fu formalizzato da Martin Fowler nel 2006 come pratica di sviluppo in cui ogni membro del team integra il proprio lavoro nel ramo principale almeno una volta al giorno, verificando ogni integrazione attraverso un build automatizzato che include l'esecuzione dei test [1]. La motivazione originaria risiedeva nella riduzione del rischio associato alle integrazioni tardive: quanto più a lungo due rami di sviluppo divergono, tanto maggiore è il costo della loro riconciliazione. Questa intuizione, apparentemente semplice, ha prodotto un cambiamento strutturale nelle pratiche di ingegneria del software che si estende fino ai modelli operativi contemporanei.
La nozione complementare di continuous delivery fu sistematizzata da Humble e Farley nel 2010, definendo un approccio in cui il software è mantenuto in uno stato costantemente rilasciabile attraverso l'automazione dell'intero percorso dal commit alla produzione [2]. Il contributo fondamentale del lavoro di Humble e Farley risiede nel concetto di deployment pipeline, ideato originariamente da Farley e Rickmeier nel 2004: una sequenza automatizzata di stadi (build, test, staging, deploy) che ogni modifica al codice attraversa prima di raggiungere l'ambiente di produzione. La distinzione tra continuous delivery e continuous deployment merita una precisazione terminologica: nel primo caso, il rilascio in produzione richiede un'approvazione esplicita; nel secondo, ogni modifica che supera tutti gli stadi della pipeline viene rilasciata automaticamente senza intervento umano.
Il panorama degli strumenti si è evoluto significativamente nell'ultimo decennio. La Continuous Delivery Foundation (CDF), fondata nel 2019 sotto l'egida della Linux Foundation, ospita oggi progetti quali Jenkins, Spinnaker, Tekton e CDEvents, con l'obiettivo di promuovere standard e pratiche vendor-neutral nell'ecosistema CI/CD [3]. Parallelamente, il modello GitOps, introdotto da Alexis Richardson di Weaveworks nel 2017, ha proposto un cambio di paradigma in cui il repository Git diventa l'unica fonte di verità non solo per il codice applicativo, ma anche per lo stato dell'infrastruttura e delle configurazioni di deployment [4]. L'adozione di queste pratiche è quantificata dal programma di ricerca DORA (DevOps Research and Assessment), i cui dati mostrano che nel 2024 i team ad alte prestazioni raggiungono una frequenza di deployment 182 volte superiore, un lead time 127 volte più rapido e un tasso di fallimento 8 volte inferiore rispetto ai team a basse prestazioni [5].
Architettura di una pipeline CI/CD
Struttura a stadi e modello di esecuzione
Una pipeline CI/CD è, nella sua forma più generale, un grafo aciclico diretto (DAG) in cui ogni nodo rappresenta un job (un'unità di lavoro eseguita in un ambiente isolato) e gli archi definiscono relazioni di dipendenza. L'esecuzione procede per stadi (stages): i job appartenenti allo stesso stadio possono essere eseguiti in parallelo, mentre stadi successivi attendono il completamento di quelli precedenti. Questa struttura consente di bilanciare la velocità di esecuzione con le dipendenze logiche tra le operazioni. GitLab CI/CD implementa questo modello attraverso il file .gitlab-ci.yml, dove gli stage sono definiti globalmente e i job all'interno di uno stage vengono eseguiti in parallelo [6]. La keyword needs consente di superare il vincolo degli stage sequenziali, permettendo a un job di dipendere direttamente dall'output di un job specifico in uno stage precedente, creando di fatto un DAG esplicito.
GitHub Actions adotta un'architettura analoga ma con una terminologia differente: un workflow è un processo automatizzato definito in YAML nella directory .github/workflows, composto da uno o più job che vengono eseguiti ciascuno in una macchina virtuale (runner) o in un container dedicato [7]. Ogni job contiene una sequenza ordinata di step, ognuno dei quali esegue uno script o invoca un'action riutilizzabile. La condivisione di dati tra step è nativa, poiché condividono lo stesso runner, mentre la comunicazione tra job richiede il passaggio esplicito di artefatti. GitHub fornisce runner hosted su Linux, Windows e macOS, ma supporta anche runner self-hosted per esigenze di conformità, prestazioni o accesso a risorse interne.
Trigger e orchestrazione degli eventi
Il meccanismo di attivazione (trigger) determina quando una pipeline viene eseguita. I trigger più comuni includono eventi di push su branch specifici, apertura o aggiornamento di merge/pull request, creazione di tag, esecuzione schedulata (cron) e invocazione manuale tramite API. La granularità del trigger ha implicazioni dirette sul feedback loop: un trigger su ogni push al branch di feature offre un riscontro immediato allo sviluppatore, mentre un trigger limitato alla merge request riduce il consumo di risorse computazionali ma ritarda la rilevazione degli errori. Le pipeline più sofisticate combinano trigger multipli con logiche condizionali che modulano la profondità dei controlli in funzione del tipo di evento e dei file modificati.
Un aspetto architetturale rilevante è la composizione delle pipeline. GitLab supporta pipeline parent-child, in cui una pipeline principale può generare pipeline figlie con configurazioni indipendenti, e pipeline multi-progetto per architetture a microservizi in cui il deployment di un servizio può dipendere dal successo della build di un altro [6]. GitHub Actions implementa un meccanismo analogo attraverso il trigger workflow_dispatch e l'evento workflow_call, che consente di invocare un workflow come action riutilizzabile da altri workflow. Queste capacità compositive sono essenziali per gestire la complessità delle architetture distribuite moderne.
Strategie di branching e trunk-based development
La relazione tra strategia di branching e efficacia della pipeline CI/CD è stata oggetto di analisi empirica rigorosa. Il programma di ricerca DORA ha dimostrato attraverso analisi statistiche su campioni di migliaia di team che i performer di livello elite hanno una probabilità 2,3 volte maggiore di adottare trunk-based development rispetto ai team a basse prestazioni [8]. In questo modello, gli sviluppatori lavorano in batch ridotti e integrano le modifiche nel trunk (ramo principale) con frequenza almeno giornaliera, mantenendo meno di tre branch attivi contemporaneamente e con una durata media dei branch inferiore a un giorno.
Il trunk-based development impone vincoli architetturali alla pipeline che ne condizionano l'efficacia. Il build e i test unitari devono completarsi in un tempo sufficientemente breve da non ostacolare il ritmo delle integrazioni: un feedback loop superiore a dieci minuti introduce un costo cognitivo che disincentiva le integrazioni frequenti. Questo requisito spinge verso l'ottimizzazione aggressiva della pipeline attraverso tecniche di caching delle dipendenze, parallelizzazione dei test e analisi selettiva dell'impatto delle modifiche (affected-target analysis). Quando la suite di test completa richiede un tempo di esecuzione incompatibile con il feedback rapido, si adotta tipicamente una strategia a due livelli: una pipeline veloce eseguita su ogni commit al trunk che include build, test unitari e analisi statica, e una pipeline completa eseguita periodicamente o prima del deployment che include test di integrazione, test end-to-end e verifiche di sicurezza.
Il modello alternativo dei long-lived feature branch, in cui le modifiche vengono sviluppate su branch separati per giorni o settimane prima dell'integrazione, si scontra con un problema fondamentale: l'integrazione ritardata amplifica il rischio di conflitti e invalida le assunzioni sulla compatibilità delle modifiche con il trunk corrente. I dati DORA del 2024 confermano questa osservazione, mostrando una correlazione negativa tra la durata media dei branch e le metriche di prestazione nella distribuzione del software [5]. Le tecniche di mitigazione, come le feature flag e il branch by abstraction, consentono di integrare codice incompleto nel trunk senza esporne il comportamento agli utenti finali, riconciliando la necessità di integrazioni frequenti con lo sviluppo incrementale di funzionalità complesse.
Strategie di testing nelle pipeline
La piramide dei test e la sua evoluzione
Il modello della piramide dei test, introdotto da Cohn nel 2009, stabilisce un principio gerarchico per la distribuzione dello sforzo di automazione dei test [9]. Alla base della piramide si collocano i test unitari: rapidi nell'esecuzione (millisecondi), economici nella manutenzione e altamente deterministici. Ogni test unitario verifica il comportamento di un'unità logica (una funzione, un metodo, una classe) in isolamento dalle dipendenze esterne. Il livello intermedio è occupato dai test di integrazione (definiti "service test" nella formulazione originale di Cohn), che verificano l'interazione tra componenti: la comunicazione con un database, l'invocazione di un'API esterna, la serializzazione e deserializzazione dei messaggi. Al vertice della piramide si trovano i test end-to-end, che simulano il percorso completo dell'utente attraverso l'interfaccia dell'applicazione.
La distribuzione quantitativa suggerita dalla piramide (molti test unitari, un numero moderato di test di integrazione, pochi test end-to-end) riflette un trade-off ingegneristico preciso. I test al vertice della piramide offrono maggiore confidenza sulla correttezza del sistema nel suo complesso, ma presentano costi significativamente superiori: tempi di esecuzione nell'ordine dei minuti o delle decine di minuti, fragilità derivante dalla dipendenza da componenti esterni e costi di manutenzione elevati per la loro sensibilità a cambiamenti nell'interfaccia utente. Il contributo di Fowler nell'articolo "The Practical Test Pyramid" ha raffinato il modello, enfatizzando che la forma della piramide non deve essere interpretata come prescrizione rigida ma come guida euristica il cui bilanciamento ottimale dipende dall'architettura del sistema e dal profilo di rischio delle modifiche [10].
Integrazione dei test nella pipeline
L'integrazione dei test nella pipeline segue una logica di progressione: i test più rapidi e deterministici vengono eseguiti per primi, fungendo da gate che impediscono l'avanzamento di modifiche manifestamente difettose verso stadi più costosi. Una struttura tipica prevede: (1) lint e analisi statica del codice eseguiti in pochi secondi; (2) test unitari con soglia di copertura minima; (3) test di integrazione con dipendenze containerizzate; (4) test end-to-end su un ambiente effimero che replica la configurazione di produzione. I risultati del report DORA 2024 evidenziano un dato significativo: l'impiego di strumenti di intelligenza artificiale nella generazione del codice correla con un aumento della dimensione media dei changeset, il che a sua volta correla con un aumento del tasso di fallimento dei deployment [5]. Questo fenomeno suggerisce che l'automazione della produzione del codice richiede un investimento proporzionale nell'automazione dei controlli di qualità, rendendo la robustezza della pipeline di test un requisito ancora più critico.
Le pipeline avanzate implementano tecniche di ottimizzazione che vanno oltre la semplice esecuzione sequenziale dei test. Il test impact analysis identifica, sulla base delle modifiche al codice, il sottoinsieme di test potenzialmente impattati, riducendo il tempo di esecuzione senza sacrificare la copertura effettiva. La test parallelization distribuisce l'esecuzione dei test su runner multipli, partizionando la suite in segmenti di durata comparabile. Il flaky test detection identifica e isola i test con comportamento non deterministico, evitando che il rumore introdotto da test instabili eroda la fiducia del team nella pipeline.
Modelli di deployment: push-based e pull-based
Il paradigma push-based
Nel modello push-based, la pipeline CI/CD è responsabile dell'intera catena: dal build dell'artefatto alla sua distribuzione nell'ambiente di destinazione. Al completamento degli stadi di build e test, uno stadio di deployment esegue comandi che modificano attivamente lo stato dell'infrastruttura di destinazione, invocando API di orchestratori, eseguendo script di configurazione o aggiornando servizi su piattaforme cloud. Jenkins, GitHub Actions e GitLab CI/CD operano nativamente secondo questo paradigma. Il vantaggio del modello push-based risiede nella sua immediatezza e nella semplicità concettuale: il flusso è lineare e la relazione causa-effetto tra commit e deployment è esplicita.
Il modello push-based presenta tuttavia vulnerabilità architetturali significative. La pipeline deve disporre di credenziali con privilegi di scrittura sull'ambiente di destinazione, creando una superficie di attacco ampia: una compromissione della pipeline, o di una delle sue dipendenze, può tradursi in un accesso diretto all'infrastruttura di produzione. Inoltre, il modello push-based non garantisce convergenza: se lo stato dell'ambiente di produzione viene modificato manualmente o da un processo esterno (configuration drift), la pipeline non rileva la discrepanza fino alla successiva esecuzione. Questo significa che lo stato effettivo del sistema può divergere silenziosamente dallo stato descritto nel repository.
Il paradigma pull-based e GitOps
Il modello pull-based, fondamento dell'approccio GitOps, inverte la direzione del controllo. Un agente (operator) installato all'interno dell'ambiente di destinazione, tipicamente un cluster Kubernetes, monitora continuamente un repository Git e, quando rileva una divergenza tra lo stato dichiarato nel repository e lo stato corrente del cluster, esegue autonomamente le operazioni di riconciliazione necessarie per riallineare i due stati [4]. In questo modello, la pipeline CI è responsabile esclusivamente del build, del test e della pubblicazione dell'artefatto in un registry; il deployment è delegato all'operator GitOps.
Argo CD è l'implementazione di riferimento del paradigma pull-based per Kubernetes. Definito come strumento di continuous delivery dichiarativo, Argo CD monitora sia il repository sorgente (Git, Helm registry o OCI image) sia lo stato corrente del cluster, sincronizzando automaticamente le divergenze [11]. L'architettura di Argo CD si articola in tre componenti principali: un application controller che implementa il loop di riconciliazione, un API server che espone l'interfaccia di gestione e un repository server che gestisce l'accesso ai manifest. Il loop di riconciliazione è il meccanismo chiave: a intervalli configurabili, il controller confronta lo stato desiderato (definito nel repository) con lo stato attuale (ottenuto dall'API server di Kubernetes) e, in caso di divergenza, può eseguire automaticamente la sincronizzazione o segnalare la discrepanza per un intervento manuale.
Flux, progetto CNCF Graduated dal novembre 2022 [12], rappresenta l'altra implementazione maggiore del paradigma GitOps. A differenza di Argo CD, che opera come applicazione monolitica, Flux v2 adotta un'architettura a controller specializzati: source-controller per la gestione delle sorgenti Git e Helm, kustomize-controller per l'applicazione delle configurazioni Kustomize, helm-controller per i rilasci Helm, notification-controller per le integrazioni con sistemi di notifica e image-automation-controller per l'aggiornamento automatico dei tag delle immagini nel repository. Questa decomposizione consente una maggiore flessibilità nella composizione dei flussi di lavoro e un isolamento più granulare dei guasti.
Trade-off tra i due paradigmi
La scelta tra modello push-based e pull-based non è binaria nella pratica. Le architetture ibride sono comuni: la pipeline CI (push-based) esegue build e test, pubblica l'artefatto e aggiorna il manifest nel repository di configurazione; l'operator GitOps (pull-based) rileva la modifica e sincronizza il cluster. Questa separazione delle responsabilità presenta vantaggi significativi dal punto di vista della sicurezza: la pipeline CI non necessita di credenziali verso il cluster di produzione, e l'operator GitOps non necessita di accesso al codice sorgente applicativo. Il principio del minimo privilegio è rispettato in modo naturale. Il costo di questa architettura è una maggiore complessità operativa e un overhead nella latenza del deployment, poiché l'operator rileva le modifiche attraverso polling periodico piuttosto che notifica immediata.
Pipeline cloud-native: Tekton
Tekton rappresenta un approccio architetturalmente distinto alla costruzione di pipeline CI/CD, trattando le pipeline come risorse native di Kubernetes (Custom Resource Definition, CRD) [13]. Originariamente sviluppato nell'ambito del progetto Knative di Google, Tekton è migrato alla Continuous Delivery Foundation e successivamente, nel 2026, al CNCF come progetto incubating. L'architettura si articola intorno a quattro primitive fondamentali: Step (un singolo comando eseguito in un container), Task (una sequenza ordinata di Step eseguita in un singolo Pod), Pipeline (un DAG di Task) e PipelineRun (un'istanza di esecuzione di una Pipeline con parametri concreti).
Il vantaggio architetturale di Tekton risiede nella sua natura Kubernetes-native. Ogni Task viene eseguita in un Pod Kubernetes, ereditando le capacità di scheduling, isolamento e gestione delle risorse dell'orchestratore. I risultati di una Task possono essere passati alla successiva attraverso i workspace (volumi Kubernetes condivisi) o i result (valori scalari propagati come parametri). Questa integrazione profonda consente di sfruttare le primitive di Kubernetes per il controllo degli accessi (RBAC), la gestione dei secret, il networking e l'osservabilità, senza introdurre meccanismi duplicati specifici della pipeline. La versione 1.0 di Tekton Pipelines ha segnato la stabilità dell'API e la maturità per l'uso in produzione, con integrazioni in piattaforme quali IBM Cloud, Red Hat OpenShift Pipelines e Google Cloud Build [13].
Il modello di esecuzione di Tekton introduce tuttavia un overhead non trascurabile: ogni Task richiede la creazione di un Pod Kubernetes, con un costo di avvio (cold start) che, in cluster con risorse contese, può incidere significativamente sul tempo complessivo della pipeline. Per pipeline con molte Task di breve durata, questo overhead può dominare il tempo di esecuzione complessivo. La mitigazione consiste nell'aggregare step logicamente correlati in una singola Task, sacrificando la granularità della composizione a favore delle prestazioni. Questo trade-off tra composabilità e latenza è caratteristico delle architetture Kubernetes-native e deve essere valutato in funzione del profilo specifico della pipeline.
Supply-chain security nelle pipeline CI/CD
Il problema dell'integrità della catena di produzione
La pipeline CI/CD è un punto di leva critico dal punto di vista della sicurezza: una compromissione della pipeline consente di iniettare codice malevolo in ogni artefatto prodotto, amplificando l'impatto di un singolo attacco a tutti i consumatori del software. L'attacco GhostAction del 2025 ha fornito una dimostrazione concreta di questo rischio: gli attaccanti hanno compromesso una GitHub Action ampiamente utilizzata modificandone il codice per esfiltrare secret da ogni repository che la referenziava tramite tag anziché tramite commit SHA, ottenendo accesso a credenziali di migliaia di repository [14]. Questo episodio ha accelerato l'adozione di pratiche di pinning delle dipendenze e di verifica dell'integrità degli artefatti nella pipeline.
Il framework SLSA
Il framework SLSA (Supply-chain Levels for Software Artifacts), sviluppato da Google in collaborazione con la OpenSSF (Open Source Security Foundation), definisce quattro livelli progressivi di garanzia sull'integrità della catena di produzione del software [15]. Il livello 1 richiede che il processo di build sia completamente automatizzato e che produca provenance: metadati firmati che attestano come un artefatto è stato prodotto, includendo il processo di build, le sorgenti e le dipendenze. Il livello 2 aggiunge il requisito di un servizio di build hosted e di provenance autenticata, impedendo che il processo di build possa essere manipolato dallo sviluppatore locale. Il livello 3 richiede che le piattaforme sorgente e di build soddisfino standard specifici di auditabilità e integrità della provenance. Il livello 4 impone la revisione a quattro occhi di ogni modifica e un processo di build ermetico e riproducibile.
L'implementazione pratica del framework SLSA nelle pipeline CI/CD si appoggia sull'ecosistema Sigstore, un progetto della Linux Foundation che fornisce firma crittografica keyless degli artefatti basata su certificati effimeri legati a identità OIDC [16]. I componenti principali di Sigstore sono Fulcio (autorità di certificazione per certificati effimeri), Rekor (registro di trasparenza immutabile) e Cosign (strumento di firma e verifica per immagini container). L'integrazione con GitHub Actions è nativa: il supporto per le attestation di GitHub utilizza Sigstore per firmare attestation in-toto, consentendo di raggiungere il livello SLSA 2 con un overhead di configurazione contenuto. L'adozione di policy engine come Kyverno consente di verificare automaticamente, al momento del deployment su Kubernetes, che ogni artefatto sia accompagnato da provenance valida e firmata, chiudendo il loop di sicurezza dalla produzione al deployment.
Limiti e problemi aperti
Nonostante la maturità raggiunta dagli strumenti e dalle pratiche di CI/CD, permangono problemi aperti che condizionano l'efficacia delle pipeline in contesti reali. La scalabilità delle suite di test rimane un problema concreto: al crescere della dimensione della codebase, il tempo di esecuzione della pipeline tende ad aumentare in modo non lineare, erodendo il feedback loop rapido che è prerequisito del trunk-based development. Le tecniche di test impact analysis e di partizionamento intelligente dei test mitigano il problema ma introducono complessità nella gestione e rischio di falsi negativi quando l'analisi delle dipendenze è incompleta.
La gestione degli ambienti effimeri per i test di integrazione e i test end-to-end rappresenta un'area di complessità persistente. La fedeltà dell'ambiente di test rispetto all'ambiente di produzione condiziona l'utilità dei test stessi: un test che passa in un ambiente semplificato può fallire in produzione a causa di differenze nella configurazione, nella scala o nelle interazioni tra servizi. Le soluzioni basate su containerizzazione e infrastructure-as-code riducono questa divergenza ma non la eliminano, particolarmente per i sistemi che dipendono da servizi gestiti esterni o da volumi di dati significativi.
Il report DORA 2024 ha evidenziato un fenomeno emergente che merita attenzione: l'impiego di strumenti di intelligenza artificiale per la generazione del codice correla con un peggioramento delle metriche di delivery performance, non perché gli strumenti siano intrinsecamente dannosi, ma perché tendono ad aumentare la dimensione media dei changeset [5]. I dati DORA mostrano in modo consistente che changeset più grandi introducono un rischio maggiore di fallimento. Questo risultato suggerisce che le pipeline CI/CD del futuro dovranno integrare meccanismi di governance automatica della dimensione delle modifiche, affiancando ai controlli di qualità tradizionali (test, analisi statica) verifiche sulla granularità dei commit.
La sicurezza della supply chain, pur avendo fatto progressi significativi con SLSA e Sigstore, presenta ancora lacune nella copertura delle dipendenze transitive e nella verificabilità end-to-end del processo di build. Il raggiungimento del livello SLSA 3 e 4 rimane un obiettivo impegnativo per la maggior parte delle organizzazioni, richiedendo investimenti significativi in infrastruttura di build isolata e processi di revisione formale. L'interoperabilità tra i diversi strumenti dell'ecosistema (CDEvents, in-toto, Sigstore, SLSA) è in fase di consolidamento ma non ancora matura, con sovrapposizioni nei formati di attestazione e nelle modalità di verifica che introducono complessità operativa.
Implicazioni pratiche
La scelta dell'architettura di pipeline CI/CD è determinata dalla combinazione di vincoli organizzativi, tecnici e di sicurezza specifici del contesto. Per team che operano su repository singoli con deployment su piattaforme cloud gestite, GitHub Actions o GitLab CI/CD offrono un percorso ad attrito minimo verso l'automazione completa del ciclo build-test-deploy. L'ecosistema di action/template pre-costruiti riduce significativamente il tempo di configurazione iniziale, al costo di un accoppiamento con la piattaforma di hosting del codice.
Per organizzazioni che operano su Kubernetes con requisiti di conformità e multi-tenancy, l'architettura ibrida CI push-based con deployment GitOps (Argo CD o Flux) offre il miglior bilanciamento tra automazione e controllo. La separazione tra pipeline CI e operatore di deployment rispetta il principio del minimo privilegio, riduce la superficie di attacco e consente audit trail completi sullo stato del cluster. Tekton si posiziona come opzione per organizzazioni che necessitano di pipeline completamente Kubernetes-native, con il vantaggio dell'integrazione profonda con l'orchestratore ma il costo di una maggiore complessità nella definizione e nell'ottimizzazione delle pipeline.
L'investimento nella supply-chain security (attestazione degli artefatti, firma crittografica, verifica della provenance) non è più opzionale per organizzazioni che distribuiscono software in ambienti regolamentati o che gestiscono supply chain software complesse. L'adozione progressiva del framework SLSA, partendo dal livello 1 (build automatizzato con provenance) e procedendo verso il livello 2 (build hosted con provenance autenticata), rappresenta un percorso incrementale che bilancia il miglioramento della postura di sicurezza con la sostenibilità dell'investimento operativo. I dati del programma DORA confermano che le pratiche di continuous delivery, quando supportate da pipeline robuste e da una cultura organizzativa che privilegia il feedback rapido e la sicurezza psicologica, producono miglioramenti misurabili e significativi nella capacità di un'organizzazione di distribuire software in modo affidabile [5, 8].
Riferimenti
[1] M. Fowler, "Continuous Integration," martinfowler.com, 2006 (ultima revisione 2024). https://martinfowler.com/articles/continuousIntegration.html
[2] J. Humble, D. Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley, 2010.
[3] Continuous Delivery Foundation, "CDF Projects," 2024. https://cd.foundation/projects/
[4] A. Richardson, "GitOps: Operations by Pull Request," Weaveworks Blog, 2017. https://www.gitops.tech/
[5] DORA Team, "Accelerate State of DevOps Report 2024," Google Cloud, 2024. https://dora.dev/research/2024/dora-report/
[6] GitLab, "CI/CD Pipelines," GitLab Documentation, 2025. https://docs.gitlab.com/ci/pipelines/
[7] GitHub, "Understanding GitHub Actions," GitHub Documentation, 2025. https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions
[8] N. Forsgren, J. Humble, G. Kim, Accelerate: The Science of Lean Software and DevOps, IT Revolution Press, 2018.
[9] M. Cohn, Succeeding with Agile: Software Development Using Scrum, Addison-Wesley, 2009.
[10] M. Fowler, "The Practical Test Pyramid," martinfowler.com, 2018. https://martinfowler.com/articles/practical-test-pyramid.html
[11] Argo Project, "Argo CD: Declarative GitOps CD for Kubernetes," 2025. https://argo-cd.readthedocs.io/en/stable/
[12] CNCF, "Flux: the GitOps family of projects," 2024. https://fluxcd.io/
[13] Tekton Authors, "Tekton Documentation," 2025. https://tekton.dev/docs/
[14] StepSecurity, "GhostActions: The Threat of Third-Party GitHub Action Compromise," 2025. https://www.stepsecurity.io/blog/ghostactions-github-actions-supply-chain-attack
[15] SLSA Project, "SLSA Specification: Security Levels," 2023. https://slsa.dev/spec/v0.1/levels
[16] Sigstore Project, "Sigstore: Software Signing for Everybody," Linux Foundation, 2024. https://www.sigstore.dev/