Ingegneria del software

DEVOPS

DevOps è una filosofia che da’ priorità alle persone più che ai processi e ai processi più

che agli strumenti e si basa su una cultura di fiducia, collaborazione e miglioramento

continuo che vede il processo di sviluppo in modo olistico, tenendo conto di tutte le

persone coinvolte nel processo di sviluppo: sviluppatori, tester, ingegneri della

sicurezza e dell’infrastruttura e addetti alle operazioni. DevOps non mette nessuna di

queste categorie al di sopra delle altre e non classifica l’importante del loro lavoro, ma

le ritiene tutte importanti allo stesso modo per offrire al cliente la migliore esperienza

possibile.

Con il termine DevOps si intende, quindi, la combinazione di Sviluppo (DEV) e

Operazioni (OPS) all’interno dello stesso team di sviluppo con l’obiettivo di accelerare

il processo di rilascio e aumentare la qualità delle applicazioni.

Le motivazioni che hanno portato alla nascita di questa filosofia sono soprattutto:

La necessità di ridurre il GAP tra lo sviluppo e le operazioni IT: storicamente,

 infatti, le due funzioni hanno sempre avuto obiettivi diversi, entrambi

fondamentali; mentre per il team di sviluppo la priorità consiste nel fornire agli

utenti il prodotto software più velocemente possibile, per le operazioni gli

aspetti fondamentali sono quelli relativi alla sicurezza e alla stabilità del sistema

in produzione. DevOps in questo senso facilita il raggiungimento di entrambi gli

obiettivi, grazie all’adozione di processi automatizzati e coerenti dallo sviluppo

all’esercizio;

La velocità del mercato e la pressione competitiva: le aziende moderne, grazie

 anche alla spinta tecnologica sempre più incalzante, hanno sempre più bisogno

di adottare modelli agili che le abilitino a portare valore in tempi rapidi. Anche in

questo contesto, DevOps consente di accelerare il processo di sviluppo software

grazie alle pratiche di integrazione continua e rilascio continuo

L’attenzione al miglioramento della qualità del software: uno degli obiettivi di un

 processo di sviluppo software è quello di ridurre gli errori e migliorare la qualità

del software rilasciato in produzione. DevOps, grazie all’implementazione delle

pratiche di test automation e all’uso di ambienti di staging equivalenti a quelli di

produzione, consente di identificare bug e problemi prima che il prodotto venga

rilasciato, garantendo un alto standard di qualità del prodotto; con pratiche poi

di monitoraggio continuo e logging centralizzato, DevOps consente alle aziende

di identificare e risolvere rapidamente anche i problemi di produzione,

migliorando la resilienza del sistema; l’utilizzo infatti dell’infrastruttura come

codice (IaC) e del deployment automatizzato consentono di creare ambienti

consistenti e ripristinare rapidamente il sistema in caso di errori;

L’avanzamento degli strumenti di automazione: il progresso e la diffusione di

 strumenti di automazione ha fornito una spinta notevole all’adozione di pratiche

d DevOps, che li utilizzano in modo spinto in tutto il ciclo di sviluppo e rilascio

del software, dal controllo di versione all’integrazione, ai test fino alla

distribuzione e al monitoraggio. L’automazione riduce, infatti, l’incidenza sul

processo degli errori umani, aumenta la velocità di esecuzione delle diverse fasi

e garantisce la coerenza nei processi di distribuzione;

L’ascesa del cloud: l’adozione di ambienti cloud, che offrono strumenti per

 l’automazione dell’infrastruttura, la gestione dei container e il supporto alla

scalabilità dei sistemi, ha reso più semplice per i team adottare un approccio

DevOps, con risorse facilmente scalabili e ambienti che possono essere creati e

distrutti rapidamente.

La cultura DevOps può essere considerata un’estensione dei modelli agile. Infatti,

mentre con agile viene incentivata la collaborazione tra il team di sviluppo ed il

cliente, DevOps aggiunge le operazioni negli stessi team.

Per facilitare questa collaborazione e garantire velocità di rilascio e qualità del

software, DevOps si basa quindi su alcuni punti chiave, in particolare:

Integrazione continua e consegna continua, ovvero i processi di CI/CD

 Implementazione di strumenti di raccolta immediata dei feedback degli utenti

 Monitoraggio delle applicazioni e dell’infrastruttura



La cultura DevOps si fonda quindi su tre assi:

Cultura della collaborazione, che è l’essenza stessa di DevOps, e per la quale i

 team non sono più separati in silos di conoscenze, ma vengono invece riuniti in

team multidisciplinari che condividono uno stesso obiettivo: fornire valore

aggiunto e di qualità il più rapidamente possibile

Processi: per far si che i rilasci avvengan rapidamente i team seguino processi

 di sviluppo basati su metodologia agile e basti qiundi su iterazioni successive

delle fasi di:

Analisi

o Implementazione

o Integrazione continua

o Consegna continua

o Distribuzione continua

o Monitoraggio continuo

o

Tutto in un contesto quanto più automatizzato possibile

Strumenti: i team DevOps utilizzano strumenti e prodotti condivisi che

 favoriscono la comunicazione su un piano comune

Come abbiamo visto, uno dei punti chiave della cultura DevOps è l’implementazione di

pipeline di integrazione continua CI e consagna continua CD.

L’ integrazione continua (Continous Integration) è il processo che consente di

verificare la completezza del codice di un’applicazione ogni volta che un membro del

team apporta una mdifica, verifica che deve essere eseguita il più rapidamente

possibile.

La CI richiede quindi l’implementazione di processi (branch, commit, pull request,

review) automatizzati per mezzo di strumenti adattati all’intero team (come Git o

Jenkins) che devono funzionare rapidamente per raccogliere feedback sull’integrazione

del codice il prima possibile ed essere in grado quindi di frnire nuove funzionalità agli

utenti più rapidamente.

Regolarmente, anche più volte al giorno, membri del team effettuano la commit del

proprio codice, preferibilmente in piccoli trunk, che possono essere facilmente risolti in

caso di errore. Tali commit vengono integrate nel resto del codice dell’applicazione,

insieme a quelli di tutti gli altri membri.

L’integrazione di tutti i commit è il punto di partenza di un processo di CI; questo

processo, eseguito sul server di CI, deve essere automatizzato e attivato ogni volta

che un membro del team fa la commit di una modifica. Il server di CI:

Recupera il codice

 Costruisce il pacchetto dell’applicazione

 Esegue i test unitari, con copertura del codice



L’utilizzo di una versione di controllo del codice sorgente come Git (SCV) è un

prerequisitio nei processi di CI poiché abilita la gestione di un ambiente di sviluppo

collaborativo; Un SCV registra ogni modifica fatta al codice, salvando versioni

incrementali e i dettagli su chi ha fatto la modifica, quando è stata fatta e cosa è stato

cambiato. Questo permette di mantenere una cronologia completa del progetto e di

consultare o recuperare qualsiasi versione passata del codice. Inoltre gli SCV

supportano la creazione di ramificazioni (branching), che consentono agli sviluppatori

di lavorare su nuove funzionalità o bugfix in parallelo senza interferire con il codice

principale (solitamente in un ramo chiamato "main" o "master" e che è l’unico ramo

facente parte del GitFlow ovvero l’unico ramo oggetto delle automazioni). Una volta

completato il lavoro, la modifica viene fusa (merged) nel ramo principale, consentendo

l'integrazione delle nuove funzionalità o correzioni. Gli SCV poi consentono di

etichettare particolari versioni del codice come release, identificando versioni

specifiche del software che sono state distribuite agli utenti e aiutan a tenere traccia

delle varie versioni pubblicate e ad applicare correzioni di bug su versioni più vecchie,

se necessario. Quando più sviluppatori lavorano sugli stessi file, il sistema di controllo

delle versioni gestisce i conflitti di modifica, fornendo strumenti per risolverli in modo

collaborativo.

Il server di CI può essere installato on-premise all’interno dei data center dell’azienda,

oppure di tipo cloud nel caso ad esempio di GitLab CI.

Abbiamo detto che le attività di CI devono essere automatizzate e tenere conto di tutti

gli elementi necessari per la verifica del codice. Queste attività in genere

comprendono la compilazione del codice, l’esecuzione di test unitari con code

coverage, l’analisi statica del codice con strumenti appositi come SonarQube. Al

termine delle attività di verifica la CI genera un pacchetto applicativo che dovrà essere

poi distribuito su diversi ambienti, chiamati anche fasi.

E’ importante che il pacchetto generato venga gestito appunto da un gestore di

pacchetti, come npm, Nexus, ecc che può essere installato on-premise oppure

distribuito in cloud. E’ importante che questo pacchetto sia neutro in termini di

configurazione dell’ambiente in modo da poter essere distribuito in ogni state e che

sia versionato in modo da poter ripristinare versioni precedenti in caso di errori.

Continous Delivery

Una volta che è stato prodotto il pacchetto software dalla CI, la fase successiva

consiste nel distribuire questo pacchetto in tutti gli ambienti che non siano di

produzione. Tale processo è appunto quello di consegna continua.

Il pacchetto di CD verrà quindi deployato nei vari ambiente, attraverso

l’implementazione di una serie di operazioni automatizzate che possono essere di

qualsiasi tipo come decomprimere file, arrestare o avviare un servizio, copiare file,

sostituire le configurazioni e così via

Mentre nella fase di CI vengono effettuati i test relativi alle singole funzioni, il processo

di CD mira a testare l’applicazione nella sua totalità e con tutte le sue dipendenze.

Nella pratica oggi è molto comune collegare CI/CD in un ambiente di integrazione:

ovvero il pacchetto generato della CI viene anche immediatamente distribuito in

ambiente di integration per consentire agli sviluppatori non solo di eseguire unit test

automatici, ma anche di verificare l’intera applicazione (con le sue interfacce e le sue

funzionalità) ad ogni commit e insieme all’integrazione degli sviluppi degli altri membri

del team.

E’ importante infine che il pacchetto generato dalla CI sia lo stesso che verrà

distribuito in ogni ambiente e che a cambiare saranno solo eventuali file esterni di

configurazione. Proprio per questo è importante integrare nel processo