07/02/2017 di Redazione

Dal DevOps al DevSecOps, l'evoluzione non è conclusa

Il nuovo paradigma di sviluppo, rilascio e aggiornamento continuo delle applicazioni non smetterà di evolversi, per esempio integrando nel circolo virtuoso la componente della sicurezza. Di questo e altro ci parla un'esperta di Ca Technologies.

immagine.jpg

Se fino a ieri si è parlato di DevOps, domani parlermo di DevSecOps. Il “terzo incomodo” fra il Development e le Operations è la Security, un elemento che sempre più dovrà essere integrato dentro al processo di sviluppo e testing delle applicazioni. È questa solo una delle tendenze individuate da Ca Technolgies, di cui ci parla Aruna Ravichandran, vice president of DevOps Solution Marketing and Management. In azienda, la manager è responsabile della commercializzazione delle soluzioni DevOps nelle diverse linee di prodotti; prima di entrare a far parte di CA Technologies, ha lavorato per Juniper Networks e Hp.

 

 

Aruna Ravichandran, vice president of DevOps Solution Marketing and Management

 

 

Negli ultimi anni si sono investite grandi quantità di tempo, energie e risorse nel tentativo di eliminare i silos in cui erano rinchiuse le funzioni di sviluppo (Dev) e gestione dell’operatività informatica (Ops). Per un valido motivo: seguendo la strategia DevOps, le organizzazioni possono accrescere notevolmente la loro agilità in ambito digitale, riducendo allo stesso tempo rischi e costi derivanti dalle nuove tecnologie. In questo 2017, però, i nuovi trend in questo ambito non riguardano espressamente l’una o l’altra componente del binomio Dev/Ops, ma hanno allargato il perimetro fino a includere anche aspetti quali testing, sicurezza e metriche.

 

Il testing non si ferma mai

Promuovere rapidamente nuovo codice in produzione è un nobile obiettivo, ma può essere anche una ricetta sicura di insuccesso digitale. Per realizzare con successo una strategia DevOps, la velocità non basta se non la si associa alla qualità. In altre parole, occorre promuovere in tempi rapidi codice di ottima qualità, e l’unico mezzo per ottenerlo è continuare a testarlo. La valenza del testing è facilmente intuibile, ma i ritmi di sviluppo sempre più serrati derivanti dall’applicazione delle pratiche DevOps ricadono pesantemente sulle spalle della funzione di testing, con la conseguenza che non è più ammissibile prevedere un’unica fase di testing all’interno del ciclo di sviluppo del software.

Di fronte all’aumentare del rischio d’impresa associato a codice di qualità meno che ottimale, alle sempre più elevate aspettative dei clienti in fatto di esperienza digitale e alla crecente competenza digitale dei concorrenti, non è più accettabile un testing di qualità “accettabile”. Il lavoro dev’essere più rigoroso e, soprattutto, capillarmente presente in tutto il ciclo di vita DevOps. I controlli non possono più essere prerogativa dei soli addetti QA (assicurazione di qualità), bensì anche gli sviluppatori devono avere la possibilità di testare il codice in corso di produzione, come prevede la metodica di “Shift Left”, secondo la quale il testing viene anticipato già alle prime fasi del ciclo di sviluppo. I test devono essere più rapidi e automatizzati. Oltre ad anticiparne l’inserimento (“Shift Left”), sia i test sia i relativi esiti dovranno essere condivisi con gli operativi. Il testing è ormai il principale ostacolo al raggiungimento di obiettivi di velocità e qualità su larga scala. Perciò prevedo che il Continuous Testing sarà al centro di grande interesse per tutto il 2017.

 

Development, Security e Operations diventano un tutt'uno: il DevSecOps

L'operatività digitale è minata anche da un'altra abitudine, quella di promuovere rapidamente codice che, pur soddisfacendo pienamente tutti i requisiti funzionali e performando in maniera efficiente su larga scala, rende l’organizzazione eccessivamente vulnerabile a eventuali cyberattacchi. Per implementare con successo questa metodologia non sono sufficienti tempi rapidi, ma occorre anche badare a soddisfare requisiti di qualità, funzionalità e sicurezza. In altre parole, deve realizzarsi un altro ribaltamento culturale: il coinvolgimento della funzione Security sin dalle prime fasi DevOps. In considerazione della crescente intensità e complessità degli attacchi informatici – e la rapidità con cui eventuali compromissioni digitali si tramutano in pubblicità negativa, provocando al marchio danni potenzialmente irreparabili – il codice non può essere solo di buona qualità, ma dev'essere anche sicuro e protetto da una solida architettura informatica.

Con l’evolversi di microservizi e Sdk, per gli sviluppatori sarà più facile incorporare la sicurezza sin dalle prime fasi del ciclo di vita, senza comunque distogliere l’attenzione dalla cura della user experience. Al momento di testare e distribuire il codice, la validazione di sicurezza dovrà essere tuttavia sottoposta a un trattamento speciale poiché i requisiti di verifica di sicurezza del codice ricadono in una categoria particolare, caratterizzata da elementi dinamici. Si potrà ricorrere al contributo di esperti e di soggetti (ad esempio, team che si occupano di governance, rischi e compliance) finora esclusi dal processo DevOps.

 

 

 

 

Metriche sotto i rilfettori

Non è sorprendente che fino a poco tempo fa fossero solo pochissime organizzazioni It avessero mostrato interesse per le metriche DevOps. È bene rammentare che per parecchie aziende è già stato alquanto difficile acquisire i processi, gli strumenti e la cultura DevOps di base. D’altro canto non si può dimenticare che è impossibile migliorare ciò che non viene misurato, ed ecco perché la continua espansione dei processi di Agile Development e DevOps deve portare ad alcuni passi avanti concreti nell’adozione e nella standardizzazione delle metriche di misurazione del successo di DevOps.

Ora che esiste una massa critica di implementazioni DevOps andate a buon fine, oltre ad alcune realtà che hanno iniziato a evolversi verso la Continuous Delivery, il mondo aziendale cercherà di perfezionare le pratiche vigenti con una gestione iterativa fondata su una serie di metriche. Le metriche possono contribuire a migliorare le pratiche digitali in diversi modi: quelle collettive possono far rilevare eventuali disservizi nei processi, ottimizzare l’allocazione delle risorse e configurare meglio le toolchain DevOps, mentre le singole metriche possono servire a individuare eventuali esigenze di coaching ed emulare i comportamenti dei top performer.

Con il crescere dell’importanza della misurazione delle esperienze DevOps, è probabile che il mercato si accordi su un insieme di metriche. Pur essendo già stati compiuti alcuni passi in questa direzione nel 2016 (come testimonia la formazione del consorzio DevOps Express), quest’anno si dovrebbero registrare alcuni progressi concreti sia nell’adozione sia nella standardizzazione delle metriche. Nel 2017 continuerà senz’altro l’attenzione verso la strategia DevOps. In corrispondenza di una sua progressiva maturazione, le organizzazioni tenderanno a estenderne il perimetro introducendo test più rigorosamente automatizzati, sofisticati controlli di sicurezza in pre-produzione e una forte disciplina di gestione per obiettivi durante tutto il ciclo di vita DevOps.

 

 

 

ARTICOLI CORRELATI