Parlando di modernizzazione dell’ICT, sempre di più si cita la “Metodologia Agile” come approccio innovativo nello sviluppo del software. Può essere utile fare il punto su cosa si intenda con questo termine, che presenta più letture già dalla pronuncia: “àgile” all’italiana, “agiàil” in british english e “àgil” in american english (ci si perdoni la semplificazione nella trascrizione fonetica).
Metodologia agile ed il framework Scrum
Tornando alla tecnica, l’agilità va qui intesa come capacità di inserire nuovi elementi di innovazione all’interno di un approccio unitario, che via via viene semplificato con una visione complessiva.
La metodologia agile è un modello di sviluppo software di tipo moderno, contrapposto al precedente modello a cascata (waterfall). Una descrizione completa è partita dal manifesto del software agile, per poi portare allo sviluppo di svariati framework, tra i quali uno dei più diffusi è lo Scrum (mischia): la metafora è lo sviluppo di software con gruppi variabili di giocatori che competono o coordinano il processo di raggiungimento dell’obiettivo finale. Lo sviluppo avviene iterando rapidi cicli, detti sprint (una delle possibili modellizzazioni dello “sprint” attraverso sei punti è stata descritta qui).
Una conseguenza del ciclo unico di sviluppo prevede che le varie competenze non siano più separate da muri funzionali, ma convergano verso una cultura unica, posseduta da più sviluppatori di nuovo tipo, detti DevOps. Nella preparazione di queste persone non c’è differenza tra sviluppo e infrastruttura. Ovviamente l’infrastruttura viene messa a disposizione in modalità diverse dalle precedenti: virtualizzate e gestibili via software.
Della sicurezza abbiamo parlato qui.
Metodologia agile: continua innovazione in C//CD
Un’altra espressione esemplificativa del cambiamento agile e di ciò che l’approccio DevOps significa è la “continuous delivery” inserita nella sintetica sigla CI/CD, che in cinque caratteri spiega che l’innovazione è componente e obiettivo nel ciclo continuo di rilascio di nuove versioni del software.
L’alternativa sarebbe prima sviluppare il nucleo centrale, poi aspettare le operations per le risorse infrastrutturali, quindi modificare il software secondo la soluzione trovata, poi aspettare la security per conferme e modifiche… e così via, con tempi lunghi e senza alcuna garanzia che il modello cosiddetto “a cascata” converga verso una soluzione funzionante.
Nella CI/CD, che ha focus finale sull’utente, guardiamo in particolare la seconda fase.
La continuous delivery va a toccare, in particolare, quattro aspetti dello sviluppo software:
- formalizzazione dei requisiti
- cicli di feedback (compilazione/test/deploy) veloci
- automazione dei processi di build, test e deploy
- ingegneria del ciclo completo dei microservizi.
Ciascuna di queste fasi è pensata per poter essere accelerata continuamente, migliorando metriche e test che rendono certo il risultato finale. Nuovi elementi possono essere via via aggiunti (sicurezza, AI, Git…) sfruttando il miglioramento continuo per ottimizzare un processo sempre più ricco e coerente con gli obiettivi.
Come in tutte le sigle, anche per CI/CD viene solitamente usata in una versione estremamente semplificata. La pipeline di sviluppo del software agile può essere correttamente descritta dalla sigla CI/CD, ma purché alla D vengano dati diversi significati.
Lo spiega bene Red Hat in un interessante articolo1. In sintesi, CD può indicare due diverse cose, distribuzione o deployment, e alle volte entrambi insieme.
Sono concetti correlati, parzialmente sovrapposti, per questo nella divulgazione sono spesso usati in modo intercambiabile. Nel mondo dello sviluppo software la loro diversità è importante.
La parte comune è l’automazione delle fasi del flusso. La parte differenziante è il livello di automazione applicato: prima si opera tra team, poi si distribuisce al cliente.
Nella D come distribuzione, le modifiche all’applicazione vengono automaticamente testate alla ricerca di bug e caricate in un repository (come il registro per container in Kubernetes, o GitHub): i team di sviluppo e quelli operativi possono comunicare operando su questi repository.
Nella D come deployment vero e proprio, si parla delle modifiche apportate dal repository alla produzione, quindi con applicazioni direttamente fruibili ai clienti. Arrivando al cliente, il singolo ciclo di innovazione si ritiene completato.
Innovazione per l’oggi e per il domani
Lo sviluppo agile del software è un processo di formalizzazione dello sviluppo che identifica metriche chiave di automazione complessiva. Rendere automatici i processi di base permette di avere idee più chiare sulle reali esigenze del business e sui vantaggi di integrazione e innovazione.
In questo modo è possibile inserire in un unico flusso di processo non solo infrastruttura e software, ma anche sicurezza (security and privacy), intelligenza artificiale e altre specifiche componenti che tradizionalmente sono affidate a team avulsi dal processo completo. Si tratta di un approccio di innovazione continua valido oggi e nel futuro.
1 Fonte: Red Hat