DevOps: cos'è, come funziona e cosa cambia con CI/CD

Il DevOps è un modo di sviluppare e gestire il software in cui sviluppo e operations lavorano come un unico team, automatizzando il percorso da una modifica del codice alla produzione perché i rilasci siano piccoli, frequenti e sicuri. La sua pratica centrale è la pipeline CI/CD: integrazione continua, continuous delivery e, dove ha senso, continuous deployment.

Il DevOps (development operations) è un insieme di pratiche ispirato alle mentalità agile e lean, basato sulla collaborazione attiva e sulla comunicazione fra tutti gli attori coinvolti nel business, per rilasciare software in maniera continua. Questa guida spiega cos'è, i principi condivisi dalla comunità, come funziona una pipeline CI/CD, la differenza tra delivery e deployment, le metriche DORA e cosa è cambiato nel 2026 con platform engineering, GitOps e controllo dei costi cloud.

TL;DR / In sintesi

• Il DevOps unisce cultura, pratiche e strumenti per consegnare software più in fretta e in modo più affidabile, eliminando la separazione tra sviluppo e operations.
• Una pipeline CI/CD automatizza build, test e rilascio: ogni modifica viene integrata, testata e resa pronta al rilascio senza passaggi manuali.
• La continuous delivery mantiene ogni modifica rilasciabile; il continuous deployment rilascia automaticamente ogni modifica che supera i test.
• Le cinque metriche DORA misurano velocità e stabilità della consegna: change lead time, frequenza di deploy, tempo di ripristino, change fail rate e deployment rework rate.
• Nel 2026 l'attenzione si è spostata su piattaforme interne, GitOps e visibilità dei costi cloud, per estendere le buone pratiche a molti team.

Cos'è il DevOps?

Il DevOps è un approccio allo sviluppo e alla consegna del software che mette al centro la collaborazione e la comunicazione tra i team di sviluppo e di operations. AWS lo descrive come la combinazione di filosofie culturali, pratiche e strumenti che aumenta la capacità di un'organizzazione di distribuire applicazioni e servizi ad alta velocità.

Questo approccio crea un ambiente di lavoro efficace e veloce, che permette alle aziende di ricevere feedback più rapidamente e di modificare i prodotti in modo più mirato. Chi costruisce un servizio condivide la responsabilità di come viene rilasciato, monitorato e corretto in produzione.

Inizialmente il DevOps veniva adottato soprattutto dalle grandi aziende legate al mondo del web, come Netflix, Google e altri colossi del settore. Con il tempo molte aziende tradizionali ne hanno introdotto i principi per adattarsi al mercato e restare al passo con i tempi.

Quali sono i principi di base del DevOps?

Il DevOps è un universo variegato e ricco di sfaccettature, ma la comunità riconosce alcuni principi di base. Gli sviluppatori integrano e testano il codice di continuo, costruiscono software rilasciabile in qualsiasi momento, modificano i sistemi senza interrompere gli utenti e migliorano il prodotto in base al feedback.

• Continuous integration and testing: gli sviluppatori integrano il codice più volte al giorno e un sistema di test automatico lo controlla ogni volta, per individuare in anticipo eventuali problemi. Così ogni nuova funzionalità non va in conflitto con l'ambiente esistente e non compromette l'uso dell'applicazione.
• Continuous delivery and deployment: il software viene costruito in modo da poter essere rilasciato, potenzialmente, in qualsiasi momento, standardizzando la configurazione delle infrastrutture.
• Continuous operations: le modifiche vengono gestite in modo da non impedire l'uso del software agli utenti finali.
• Continuous assessment: il team lavora sul prodotto in base al feedback, in particolare i feedback loop, cioè la registrazione dell'esperienza degli utenti per tutto il ciclo di vita del prodotto, e la planning prioritization, cioè l'assegnazione di una priorità a ogni feedback nel momento in cui arriva.

Come funziona una pipeline CI/CD?

Una pipeline CI/CD è il percorso automatico che ogni modifica del codice segue fino alla produzione. Lo sviluppatore fa commit; la pipeline compila, esegue i test automatici, crea un artefatto versionato, lo distribuisce in un ambiente di test o staging, esegue altri controlli e poi lo rilascia, con approvazione o in automatico. Il monitoraggio chiude il ciclo.

Le pipeline cambiano da team a team. Una pipeline tipica ha queste fasi:

1. Commit: una piccola modifica viene inviata al repository condiviso, idealmente più volte al giorno.
2. Build: il codice viene compilato e le dipendenze risolte in un ambiente pulito e ripetibile.
3. Test automatici: test unitari, di integrazione e di sicurezza girano su ogni modifica; un errore ferma la pipeline.
4. Pacchetto: la build produce un unico artefatto versionato, per esempio un'immagine container, promosso senza modifiche in tutti gli ambienti.
5. Deploy in staging: l'artefatto viene distribuito in un ambiente configurato come la produzione, tramite infrastructure as code.
6. Controlli di accettazione: test end-to-end, di performance e di accessibilità confermano che la modifica si comporta come previsto.
7. Rilascio: la modifica va in produzione, con approvazione manuale nella continuous delivery o in automatico nel continuous deployment.
8. Monitoraggio: log, metriche e alert mostrano come si comporta la modifica per gli utenti reali e alimentano l'iterazione successiva.

La regola chiave è che è la pipeline, non una persona, a decidere se una modifica è pronta. Se un passaggio fallisce, il team sistema pipeline o codice prima di fare altro, così il ramo principale resta sempre rilasciabile.

Che differenza c'è tra continuous integration, delivery e deployment?

La continuous integration consiste nell'unire spesso le modifiche in un repository condiviso e testarle in automatico. La continuous delivery rende ogni modifica che supera i test pronta per la produzione in qualsiasi momento, con una persona che decide quando rilasciare. Il continuous deployment elimina questa decisione e rilascia tutto ciò che supera i test.

La continuous delivery è definita come la capacità di portare in produzione, o nelle mani degli utenti, modifiche di ogni tipo, comprese nuove funzionalità, configurazioni, correzioni ed esperimenti, in modo sicuro, rapido e sostenibile. Il continuous deployment è sicuro solo quando test, monitoraggio e rollback sono abbastanza solidi da non richiedere un controllo manuale di ogni rilascio.

Quali vantaggi porta il DevOps?

Il DevOps rende il flusso di lavoro più elastico e fluido. I rilasci diventano più piccoli e frequenti, e quindi più controllabili; il time to market migliora; sprechi e costi si riducono nel lungo periodo. I vantaggi nascono proprio dalla dimensione ridotta dei rilasci: ognuno comporta meno rischio, è più facile da testare e più rapido da correggere.

• Time to market più rapido: automatizzare sviluppo e rilascio accorcia i tempi per consegnare nuove funzionalità.
• Più collaborazione e comunicazione: eliminare la separazione tra sviluppo e operations porta a software migliore e a meno ritardi nei passaggi di consegna.
• Più affidabilità e qualità: ogni modifica viene testata e verificata prima di arrivare in produzione, quindi meno difetti raggiungono gli utenti.
• Uso più efficiente delle risorse: automazione e meno sprechi riducono il lavoro manuale e i costi.

Come si misurano le prestazioni DevOps?

Il modo standard di misurare le prestazioni DevOps sono le metriche DORA. DORA ne ha individuate cinque: change lead time, frequenza di deploy e tempo di ripristino dopo un deploy fallito misurano la velocità; change fail rate e deployment rework rate misurano l'instabilità. Seguite nel tempo, mostrano se la consegna diventa più rapida e sicura.

Secondo DORA, il change lead time è il tempo che una modifica impiega dal commit nel controllo di versione al deploy in produzione. La frequenza di deploy è il numero di rilasci in un periodo, e il tempo di ripristino è quanto serve per recuperare da un deploy che fallisce e richiede un intervento immediato.

Sul fronte dell'instabilità, il change fail rate è la quota di deploy che richiedono un intervento immediato, di solito un rollback o un hotfix. Il deployment rework rate è la quota di deploy non pianificati causati da un incidente in produzione. DORA ha sostituito il precedente modello a quattro metriche, che usava il tempo medio di ripristino, con questo modello a cinque.

Quali sono le buone pratiche DevOps nel 2026?

Le pratiche che contano di più sono modifiche piccole e frequenti su un ramo principale condiviso, test automatici su ogni modifica, infrastruttura definita come codice, controlli di sicurezza nella pipeline e un monitoraggio che mostri come si comporta ogni rilascio. Gli strumenti cambiano in fretta, questi principi no.

• Piccoli lotti: integrare le modifiche almeno una volta al giorno e tenere i rami di breve durata, così conflitti ed errori restano piccoli.
• Test automatici: test unitari, di integrazione ed end-to-end girano nella pipeline; un test fallito blocca il rilascio.
• Infrastructure as code: server, reti e configurazioni sono definiti in file versionati, non modificati a mano.
• Sicurezza nella pipeline: analisi delle dipendenze, rilevamento dei segreti e analisi statica su ogni modifica, non una volta sola prima del rilascio.
• Osservabilità: log, metriche e trace fanno parte di ogni servizio, con alert che hanno un responsabile.

Gli strumenti sono cambiati, le basi no. L'integrazione continua segue ancora le pratiche descritte da Martin Fowler nel suo articolo sulla continuous integration: tutto in una mainline sotto controllo di versione, una build automatica che si testa da sola e commit sulla mainline da parte di tutti, ogni giorno.

Cosa sono il platform engineering e il GitOps?

Il platform engineering consiste nel costruire una piattaforma interna che offra ai team di sviluppo percorsi pronti e self-service per costruire, rilasciare e gestire il software. Il GitOps è un modo di gestire questa piattaforma in cui lo stato desiderato dei sistemi è dichiarato in Git e degli agenti software allineano di continuo i sistemi in esecuzione.

La CNCF definisce una piattaforma per il cloud-native come un insieme integrato di capacità definite e presentate in base alle esigenze dei suoi utenti. In pratica, un nuovo servizio riceve pipeline, ambienti, monitoraggio e impostazioni di sicurezza da modelli già pronti, invece di ricostruirli ogni volta.

I principi OpenGitOps definiscono il GitOps in quattro punti. Lo stato desiderato è dichiarativo, versionato e immutabile, prelevato automaticamente da agenti software e riconciliato di continuo con lo stato reale. Ogni modifica alla produzione diventa così una modifica revisionata in Git, con cronologia completa e rollback semplice.

Come incide il DevOps sui costi del cloud?

Il DevOps rende facile creare ambienti e risorse, ed è per questo che può far crescere in fretta la bolletta del cloud. La soluzione è trattare il costo come un segnale di qualità: etichettare le risorse per team e servizio, mostrare il costo per ambiente nelle stesse dashboard delle prestazioni ed eliminare in automatico le risorse inutilizzate.

Ambienti di test temporanei distrutti a fine pipeline, autoscaling sul carico reale e spegnimento degli ambienti non di produzione fuori orario sono le risposte DevOps più comuni. Le revisioni dei costi vanno fatte con lo stesso ritmo di quelle sulla consegna, perché tecnici e finanza guardino gli stessi numeri.

È il campo del FinOps, che mette insieme ingegneria, finanza e business sulla spesa cloud. Il servizio WWG di ottimizzazione FinOps parte da un'analisi della spesa cloud reale, mentre il servizio di migrazione al cloud aiuta a progettare i costi fin dall'inizio.

Quando conviene un team DevOps esterno?

Un team DevOps esterno conviene quando i rilasci sono ancora manuali e rischiosi, quando nessuno in azienda è responsabile di pipeline e infrastruttura, o quando una migrazione o una nuova piattaforma richiede competenze che il team non ha ancora. L'obiettivo deve essere un processo di consegna che il tuo team sappia gestire, non una dipendenza permanente.

I servizi di consulenza DevOps di WWG servono a rendere la consegna ripetibile: automatizzare build, test e rilascio, definire l'infrastruttura come codice, introdurre monitoraggio e alert e cambiare le pratiche intorno a tutto questo. Così i rilasci smettono di essere eventi straordinari.

A volte serve capacità dentro il proprio team più che un progetto. In quel caso, ingegneri DevOps dedicati possono occuparsi di pipeline, definizioni dell'infrastruttura e monitoraggio insieme ai tuoi sviluppatori.

Domande frequenti

Il DevOps è un ruolo o una cultura?

Il DevOps è prima di tutto una cultura e un insieme di pratiche condivise da sviluppo e operations, non un singolo ruolo. Molte aziende assumono comunque ingegneri DevOps, che costruiscono e mantengono pipeline, infrastruttura e monitoraggio. Il ruolo funziona meglio quando permette a ogni team di rilasciare in autonomia, invece di diventare un nuovo livello tra sviluppatori e produzione.

Quali strumenti si usano in una pipeline CI/CD?

Una pipeline combina di solito un repository Git, un server CI/CD come GitHub Actions, GitLab CI o Jenkins, un registry di container, uno strumento di infrastructure as code come Terraform e strumenti di monitoraggio e alert. Gli strumenti specifici contano meno dell'automazione di ogni passaggio e della definizione della pipeline sotto controllo di versione.

Il DevOps serve anche alle piccole aziende?

Sì. Una piccola azienda adotta spesso il DevOps più facilmente di una grande, perché ha meno team e meno passaggi di consegna. Automatizzare test e rilasci, tenere l'infrastruttura sotto controllo di versione e condividere la responsabilità della produzione porta gli stessi vantaggi anche in piccolo, ed elimina i passaggi manuali che rallentano di più un team ridotto.

Il DevOps sostituisce il team di operations?

No, cambia il modo in cui lavora. Gli specialisti di operations passano dal gestire a mano ogni rilascio al costruire piattaforme, automazioni e monitoraggio che permettono agli sviluppatori di rilasciare in sicurezza. La responsabilità della produzione diventa condivisa, mentre le operations si concentrano su affidabilità, sicurezza e costi di tutti i servizi.

Per rendere i tuoi rilasci più rapidi e sicuri, scrivici a info@wwg.it.

Fonti

• Amazon Web Services, Cos'è DevOps? — https://aws.amazon.com/it/devops/what-is-devops/
• Continuous Delivery (Jez Humble), What is Continuous Delivery? — https://continuousdelivery.com/
• DORA, DORA's software delivery performance metrics — https://dora.dev/guides/dora-metrics/
• Martin Fowler, Continuous Integration — https://martinfowler.com/articles/continuousIntegration.html
• CNCF TAG App Delivery, Platforms white paper — https://tag-app-delivery.cncf.io/whitepapers/platforms/
• OpenGitOps, GitOps principles v1.0.0 — https://opengitops.dev/