Il mondo software degli ultimi anni è stato condizionato da molteplici e inevitabili cambiamenti, di cui la proliferazione dell’Open Source e l’implementazione del DevOps sono una dimostrazione.
Questi cambiamenti, come degli “spostamenti tettonici”, presentano un rovescio della medaglia: la mancata gestione dei componenti Open Source può portare in “superficie” aree a rischio, difficili da controllare e mantenere.
Le aziende leader nei settori bancario e assicurativo, ad esempio, hanno cercato di far fronte a queste problematiche molto presto, definendo programmi di governance dell’Open Source centralizzati e altamente strutturati. Generalmente, questi programmi prevedono dei processi attraverso i quali gli sviluppatori richiedono il permesso di utilizzare determinati componenti; le richieste sono poi valutate da esperti di sicurezza e architetture, che hanno stilato la lista di componenti “accettabili per l’uso”, spesso creando un “repository d’oro” accessibile agli sviluppatori.
Fino a poco tempo fa, questo genere di approccio rappresentava una vera e propria best practice. Oggi, invece, questi programmi sono incongruenti con le moderne pratiche di sviluppo per quattro semplici ragioni:
Tempo: i tempi delle richieste di approvazione variano generalmente dalle 6 alle 12 settimane. A volte sono più lunghi per i progetti di più grandi dimensioni, o più brevi per incrementi di versione di progetti già approvati.
Esigenze contrastanti: i lunghi cicli di approvazione non sono compatibili con le richieste di innovazione da parte del business e gli sviluppatori utilizzano spesso metodi creativi per aggirare mandati incompatibili. Un esempio è quello di un team di sviluppo che utilizza i componenti ritenuti necessari, rinominandoli però in modo tale da farli apparire come se fossero presenti all’interno della lista.
Deterioramento: il software dura quanto il latte, non quanto il vino. Ciò che è perfettamente accettabile un giorno, può diventare estremamente rischioso il giorno dopo.
Volume: più di 7.000 nuovi progetti e 70.000 componenti Open Source (versioni) vengono rilasciati ogni settimana! Le interdipendenze tra questi componenti sono quasi incalcolabili e i volumi di utilizzo sono notevoli (nel 2016 sono state conteggiate 52 miliardi richieste di download di componenti).
Quindi? Sta diventando sempre più evidente che, così come abbracciamo la DevOps transformation, dovremmo anche abbracciare una “governance transformation”.
Quali sono i concetti che consentono il successo delle iniziative DevOps?
Scalare: la funzione di governance deve operare in tempo reale all’interno del flusso DevOps. Ovviamente, questo è possibile solo attraverso l’automazione.
L’automazione richiede policy chiare, metadati estremamente precisi e la capacità di identificare esattamente un determinato componente.
Presto: l’identificazione del problema, su scala, è relativamente priva di valore di per sé. Affinché un programma di governance DevOps possa realizzare il suo pieno potenziale, i problemi devono essere identificati il più presto possibile, con dettagli di risoluzione nitidi, chiari e facilmente utilizzabili dagli sviluppatori con gli strumenti già utilizzati. La riduzione o l’eliminazione del rework è un valore trainante fondamentale.
Ovunque: la governance automatizzata dovrebbe riguardare l’intera catena DevOps, e non solo alcuni processi.
Ironia della sorte, le aziende che per prime hanno compreso le sfide dello sviluppo software moderno seguono ora i programmi di governance più radicati e tradizionali (manuali). Senza dubbio, per quanto impegnativo possa essere rimodellare questi programmi, i processi umani sono incompatibili con il DevOps e con gli obiettivi di Continuous Delivery.
In futuro, concetti e competenze waterfall giocheranno ancora un ruolo fondamentale, ma all’interno dei pattern dei processi DevOps.
