Elementi cardine della trasformazione digitale, come il cloud computing, continuano a favorire la modernizzazione dell’IT, l’innovazione, la creazione di nuovi modelli di business. Il fulcro di questa innovazione è il software, la sua qualità, affidabilità, ma anche la velocità e frequenza con cui viene sviluppato e rilasciato. Indipendentemente dal settore in cui opera, qualunque impresa oggi ha l’esigenza di potenziare il proprio core business sviluppando una gamma di evoluti servizi digitali, che sono richiesti dagli utenti finali e aiutano a differenziare l’impresa stessa dai concorrenti.
Serve però implementare un modello, un ciclo di sviluppo e distribuzione del software, più moderno, agile, rapido: e la risposta a queste necessità, nella prospettiva di Sorint.lab, società che nel settore fornisce servizi di consulenza e system integration, si realizza nel connubio tra approccio di sviluppo Agile e metodologia CI/CD, acronimo che sta per integrazione continua e distribuzione continua.
Necessità di rilasci veloci e frequenti
“Oggi il mercato, gli utenti – spiega Luigi Leoni, in Sorint.lab responsabile del team di pratiche DevOps – richiedono software di qualità, rilasci veloci e frequenti, per integrare continui cambiamenti all’interno dei propri applicativi. In tale contesto, ormai da anni, l’approccio Agile è quello preferenziale, perché permette di modificare in corso d’opera le funzionalità e servizi che si vogliono implementare nell’applicazione”.
La tecnica Agile consente, in sostanza, di accelerare il ciclo di sviluppo, superando i limiti del tradizionale paradigma ‘waterfall’, in cui il processo di sviluppo avviene in modalità sequenziale, e dove solo alla fine del ciclo l’utente della soluzione ha la possibilità di verificare e valutare se il prodotto software soddisfa requisiti e obiettivi del progetto.
“Agile è invece un approccio iterativo, incrementale, in cui, insieme, i membri del team di sviluppo definiscono gli obiettivi fondamentali del progetto, dividendolo in ‘macrotask’, che poi vengono scomposti in moduli, a loro volta suddivisi in attività: tale pianificazione, tipicamente basata su un ciclo di due settimane, viene denominata ‘sprint’. Terminate le due settimane di progettazione iterativa, se tutto è andato per il meglio, il prodotto potrà essere rilasciato in ambiente di produzione con quel set di funzionalità sviluppate. Dopodiché, l’iter ricomincia, e si ripianificano le nuove attività da inserire nel ciclo dello sprint successivo”.
Agile e integrazione continua, uno binomio inevitabilmente stretto
L’approccio Agile fornisce il vantaggio di recepire e attuare con rapidità e flessibilità le modifiche applicative richieste dall’utente grazie alla ripianificazione degli sprint. Tuttavia, precisa Leoni, per massimizzare i benefici che porta nel ciclo di sviluppo software (SDLC), Agile deve poter interoperare strettamente con la metodologia CI/CD.
“È fondamentale chiarire che la tecnica di sviluppo Agile può funzionare pienamente solo quando viene completata introducendo la tecnica di integrazione continua e distribuzione continua del software, che rappresenta lo strumento in grado di automatizzare il ciclo di generazione e rilascio del pacchetto applicativo”. In particolare, nella pipeline CI/CD, la componente CI (continuous integration) è quella che permette d’integrare velocemente le modifiche apportate al codice, e, eseguiti i necessari test, di rimpacchettarlo in una nuova ‘build’ software.
“Inoltre – chiarisce Leoni – quando il processo CI viene implementato in modo corretto, permette agli sviluppatori di osservare gli impatti dell’attività di sviluppo sul ‘main branch’ del codice. Quindi è possibile verificare se si sono manifestati ‘side effects’, effetti indesiderati nel codice sorgente, oppure se le modifiche applicative sono andate a buon fine”.
Come costruire competenze Agile e CI/CD
Le imprese che decidono d’innovare il proprio ciclo di sviluppo software per realizzare rapidamente applicazioni e servizi digitali moderni hanno però di fronte diverse sfide, non solo di carattere tecnico. In molte realtà aziendali, mancano le competenze per adottare queste metodologie e strumenti di creazione del software, ma, soprattutto, in certi ambienti IT non esiste la cultura, il mindset necessario per utilizzarli con profitto. Come affrontare questi problemi?
“In primo luogo, naturalmente sulla base delle specifiche esigenze aziendali, formiamo figure tecniche, sia per quanto riguarda la conoscenza e l’utilizzo dell’approccio Agile, sia per l’implementazione della toolchain richiesta per realizzare una pipeline CI/CD tagliata su misura per il singolo caso d’uso. Sorint.lab è in grado d’integrare con queste figure professionali il team di sviluppo dell’azienda utente, o anche di crearlo da zero”.
Una delle sfide più impegnative, negli ambienti IT più conservativi, come quelli appartenenti al mondo bancario e finanziario, è però saper gestire le resistenze interne che frenano la completa instaurazione di una cultura DevOps e la trasformazione dei processi di sviluppo e distribuzione del software. “I risultati ottenibili, chiaramente, dipendono da quanto l’azienda utente è realmente interessata a questo tipo di approccio, cioè da quanto è disposta ad abbassare il muro, la tradizionale separazione, tra il team di sviluppo e il team delle operation.
Approccio Agile e metodo CI, per funzionare con la massima efficienza, devono potersi raccordare con la distribuzione continua del codice, CD, e ciò significa necessariamente introdurre e sviluppare nell’ambiente IT una cultura DevOps. Il problema, qui, è, solitamente, superare le resistenze esistenti nel team operation, che tende a mantenere il tradizionale modello di controllo sulla fase di delivery del software in produzione, sostenendo “erroneamente” che le pratiche DevOps violano la ‘segregation of duties’. L’adozione delle pratiche DevOps e l’utilizzo di workflows di deployment opportunamente progettati, garantiscono e rafforzano la SoD, impendendo al team di sviluppo di rilasciare software autonomamente in ambienti produttivi ed allo stesso modo impediscono al team di operation di alterare il package applicativo generato dal team di sviluppo”.
Contributo editoriale sviluppato in collaborazione con Sorint
