DevOps è un insieme di pratiche, strumenti e abitudini che avvicina chi sviluppa il software (Dev) e chi lo gestisce in produzione (Ops). L’obiettivo è facile da dire: portare una modifica dal computer di uno sviluppatore agli utenti in modo rapido, ripetibile e sicuro.
Per chi decide in azienda conta meno l’elenco degli strumenti e più il percorso. Ogni modifica, che sia una nuova funzione o la correzione di un errore, segue sempre la stessa strada, controllata dalle macchine dove possibile e dalle persone dove serve. Quando questa strada esiste, rilasciare smette di essere un evento e diventa routine.
Qui la seguiamo tappa per tappa, con gli strumenti più diffusi e qualche esempio dai nostri progetti.
Versioni: branch e pull request
Tutto parte da Git, il sistema di controllo delle versioni. Ogni modifica nasce in un branch, una linea di lavoro separata, e torna nel ramo principale con una pull request (merge request in GitLab): una richiesta di integrazione che un collega rivede prima di approvarla. Il ramo principale è protetto, nessuno ci scrive direttamente, e le modifiche restano piccole, così la revisione è reale e non una formalità.
Questo ritmo si sposa con quello degli sprint, che descriviamo nel nostro articolo su Agile Scrum: ogni storia diventa una o più modifiche piccole, revisionate e integrate presto.
Integrazione continua: i controlli automatici
La CI (continuous integration, integrazione continua) è una pipeline, cioè una sequenza di passi automatici, che parte a ogni modifica proposta:
- Build: compila il progetto e ne risolve le dipendenze.
- Test: unitari, di integrazione e, dove servono, end-to-end sull’interfaccia.
- Qualità: linter e analisi statica, per esempio con SonarQube, con soglie che bloccano il merge.
- Sicurezza: scansione del codice (per esempio con Semgrep), delle librerie con vulnerabilità note e dei segreti finiti per errore nel repository.
Se un passo fallisce, la modifica non entra. Gli strumenti più diffusi sono GitHub Actions, GitLab CI/CD e Jenkins; in tutti la pipeline è descritta in un file che vive nel repository insieme al codice, quindi è versionata e revisionata come il resto.
Container: lo stesso pacchetto in ogni ambiente
Superati i controlli, la pipeline crea un’immagine container: un pacchetto, di solito costruito con Docker, che contiene l’applicazione con tutto ciò che le serve per girare. L’immagine si costruisce una volta sola, riceve un’etichetta legata alla versione e viene salvata in un registro; poi la stessa immagine passa dal collaudo alla produzione. È la fine del classico “sul mio computer funziona”.
I container non sono solo cloud: nell’ERP per le gare di Atac, sviluppato per Ernst & Young, ogni microservizio gira in un container Docker sul sistema on-premise del cliente.
Rilascio automatico negli ambienti
Il rilascio continuo (continuous delivery) porta l’immagine negli ambienti, di solito sviluppo, collaudo e produzione, con la stessa procedura automatica. Dove i servizi sono molti e devono scalare si usa spesso Kubernetes, che distribuisce i container sui server, li riavvia se cadono e aggiorna le versioni un po’ alla volta; in altri casi bastano i servizi gestiti dei cloud provider o un singolo server con Docker. La scelta dipende dal progetto, non dall’abitudine.
Due esempi dai nostri lavori. In 2VitaBCognitive per Atlantia il rilascio dei 6 microservizi passa da AWS CodeCommit, CodePipeline e CodeDeploy, e i servizi girano in container Docker su Amazon ECS. In ATS, il nostro sistema di selezione del personale, GitHub Actions porta il codice in Docker sul server, dietro Caddy, con backup e ripristino automatico.
Infrastruttura come codice
Anche server, reti e database si descrivono in file versionati. Con Terraform (o il suo fork open source OpenTofu) si dichiarano le risorse cloud, con Ansible si configurano i server. Il vantaggio è concreto: gli ambienti si ricreano identici, le modifiche all’infrastruttura passano dalla revisione come il codice e, dopo un guasto, si riparte da una descrizione nota e non dalla memoria di qualcuno.
Monitoraggio, allarmi e rollback
Il lavoro non finisce con il rilascio. Prometheus raccoglie le metriche (tempi di risposta, errori, uso delle risorse), Grafana le mostra in cruscotti e gli allarmi avvisano il team quando una soglia viene superata, possibilmente prima che se ne accorgano gli utenti. I log centralizzati aiutano poi a capire cosa è successo.
Quando un rilascio va male serve il rollback, cioè il ritorno alla versione precedente. Con le immagini versionate basta rimettere in servizio quella di prima; il punto delicato sono i dati, quindi le modifiche al database vanno pensate per restare compatibili con la versione precedente almeno per un rilascio.
La parte che non si automatizza
DevOps è prima di tutto un modo di lavorare:
- Rilasci piccoli e frequenti: una modifica piccola si rivede meglio, si prova meglio e, se serve, si annulla in fretta.
- Responsabilità condivisa: chi sviluppa segue anche il comportamento in produzione, e chi gestisce l’infrastruttura partecipa alle scelte di progetto.
- Analisi senza colpevoli: dopo un incidente si cerca la causa nel processo, non una persona da accusare, e si aggiunge un controllo perché non si ripeta.
- Misure condivise: le ricerche DORA (DevOps Research and Assessment) hanno reso comuni indicatori come la frequenza dei rilasci, il tempo dalla modifica alla produzione, la quota di rilasci che causano problemi e il tempo di ripristino.
Se volete costruire o rivedere la strada che porta il vostro codice in produzione, o affiancare al vostro un team che lavora già così, parliamone.
