Per riuscire a ricavare dall’adozione di DevOps i massimi benefici che potenzialmente è in grado di fornire alle imprese, occorre applicarlo il più possibile in maniera completa, in modo da coprire l’intero ciclo di sviluppo e distribuzione del software. Ciò, tuttavia, non è sempre facilmente praticabile, soprattutto in quegli ambienti IT fortemente regolati che caratterizzano certi settori aziendali. Tra questi c’è il mondo finance, ma anche l’industria assicurativa, il manufacturing o l’assistenza sanitaria. Per spiegare perché, prima di tutto, va ricordato cos’è e come funziona DevOps.
DevOps è un moderno paradigma di sviluppo di applicazioni e servizi che ha l’obiettivo di far raggiungere alle squadre di lavoro la massima agilità e velocità nella progettazione e distribuzione del codice. Per ottenere questo obiettivo, uno dei principi fondamentali su cui si fonda DevOps è l’instaurazione di maggior comunicazione e collaborazione tra i team dedicati alle attività di sviluppo software (Dev) e i team che sono invece concentrati sulle attività di gestione delle IT operation (Ops), necessarie per mettere tale software in produzione.
L’altro essenziale aspetto di DevOps che concorre ad accelerare il ciclo di sviluppo e distribuzione del software è l’automazione di varie operazioni, realizzabile attraverso l’adozione di strumenti che permettono d’implementare la cosiddetta pipeline CI/CD (continuous integration e continuous delivery). Quest’ultima è costituita da una serie di operazioni e fasi e di elaborazione del codice che vengono automatizzate da determinati tool software e permettono l’integrazione continua e la distribuzione continua del codice stesso.
DevOps non infrange la ‘segregation of duties’
Nelle organizzazioni IT appartenenti a settori industriali soggetti a normative particolarmente stringenti, succede però che la pipeline CI/CD possa essere implementata solo parzialmente, a causa dell’esistenza di framework di controllo come la cosiddetta ‘segregation of duties’ (SoD), o separazione dei compititi.
In genere, infatti, il team di gestione delle IT operation tende a voler continuare a mantenere la tradizionale modalità di controllo (spesso manuale) sul rilascio del software applicativo in produzione per la preoccupazione che, applicando la procedura CD, le regole SoD verrebbero infrante.
Premesso che nelle organizzazioni IT possono sussistere, e presentarsi, tutti gli scenari possibili, va però sgombrato il campo da pregiudizi e chiarito un aspetto: adottare DevOps e il processo CD in questi ambienti IT non significa necessariamente abbandonare le tradizionali regole SoD, instaurate per mantenere la governance nel processo di sviluppo e fornitura del software.
Come anticipato, tali regole distinguono soprattutto il modo di operare di certe grandi realtà aziendali fortemente regolate, come possono essere le imprese bancarie e quelle che operano nel settore finance, dove esiste particolare attenzione alla conformità con le normative, così come ai problemi di sicurezza. Qui, l’adozione di procedure non conformi alle regole SoD può elevare i rischi di sicurezza e privacy e portare a violazioni dei sistemi e delle applicazioni, con gravi conseguenze sull’attività di business che si riflettono in perdita di clienti e deterioramento della reputazione aziendale.
Al fine di garantire il controllo, e la protezione delle applicazioni e dei dati dei clienti, le regole SoD separano ruoli e compiti, limitando il livello di permessi e privilegi posseduti da coloro che lavorano nei team addetti allo sviluppo e alla distribuzione del software.
Quindi, tipicamente, chi si occupa di sviluppo software, e può apportare modifiche al codice in ambiente di sviluppo, non è autorizzato a implementare tali cambiamenti anche in ambiente di produzione. In questo modo è possibile minimizzare i rischi di violazione delle applicazioni.
Ciò però, nella transizione verso DevOps, può portare a un inconveniente: se, nel rispetto delle regole SoD, solo il team delle operazioni IT può eseguire il rilascio del software in produzione, ma lo fa procedendo ancora in maniera tradizionale, cioè senza strumenti di automazione, il funzionamento della pipeline CI/CD si ferma, in sostanza, alla fase di integrazione continua (CI) del codice in ambiente di sviluppo.
Automatizzare delivery e deployment mantenendo la SoD
Implementare a metà il modello DevOps, fermandosi alla fase CI, senza automatizzare anche le fasi di delivery e deployment in produzione ma gestendole ancora in modalità manuale, vuol dire cogliere solo alcuni benefici e accelerare parzialmente il processo di fornitura del software.
La domanda è, allora, quale soluzione adottare per massimizzare i benefici di DevOps anche in ambienti IT fortemente conservativi come quello finanziario, implementando in toto CI/CD.
“Anche in queste realtà – spiega Luigi Leoni, responsabile del team di pratiche DevOps all’interno della società di servizi e consulenza IT Sorint.lab – l’approccio dev’essere la creazione, tramite l’utilizzo di opportune toolchain di strumenti, di pipeline che semplificano e velocizzano la delivery, senza la richiesta di operazioni manuali, come invece le IT operation sono abituate a fare tradizionalmente”.
Il successo di questo approccio dipende, però, da quanto il team delle operazioni IT è disposto ad accettare il nuovo modo di lavorare e ad automatizzare la delivery, abbracciando la cultura DevOps. “Quello che ancora si fa fatica a far comprendere è che, anche con l’introduzione della cultura DevOps, la SoD può essere mantenuta”. Insomma, il team delle operazioni IT, e non quello degli sviluppatori, può continuare a occuparsi di eseguire il rilascio di una determinata versione del software applicativo in ambiente di produzione. La differenza è che, invece di mettere mano fisicamente ai sistemi, e aumentare il rischio di errori, il team delle operazioni IT deve utilizzare appositi strumenti di automazione della toolchain CI/CD per attuare la delivery del codice con le modifiche su un ambiente produttivo.
