L'approccio DevOps - Sviluppo software e web

Indice

1. Introduzione
2. Continuous Integration
3. Continuous Delivery
4. Continuous Deployment
5. Cos’è Jenkins?
6. Conclusioni

 

 

Introduzione

Automatizzare i processi di sviluppo al fine di ottimizzare le migliori pratiche è ciò che al giorno d’oggi viene chiesto ai programmatori.

Tale richiesta, in linea con la necessità di una maggiore velocità nella messa in produzione di software e applicazioni, trova la sua definizione più generale nel concetto “DevOps”.

L’approccio DevOps è, infatti, un modello secondo il quale gruppi di sviluppo interfunzionali programmano in maniera più rapida, ma pur sempre rilasciando progetti e soluzioni di alta qualità e sicure sia nei tradizionali ambienti d’uso sia in cloud.

DevOps, un concetto formato da due termini significativi in fase di sviluppo: “development” e “operations”, concetti che indicano più che adeguatamente questa nuova tendenza che vede nuovi livelli di condivisione e di integrazione consolidarsi tra gli sviluppatori e tra gli addetti alle operations al fine di accelerare i tempi di progettazione, di testing e di rilascio dei software aziendali.

Dunque, una metodologia di sviluppo del software che si avvale delle nuove logiche della condivisione e della collaborazione fra programmatori allo scopo ben preciso di rendere la programmazione più veloce in ogni sua fase, ma allo stesso tempo assicurando un alto grado di qualità e di sicurezza del software finale.

Una tendenza che, nel tempo, ha dato origine a una serie di termini e metodologie più specifiche nate al fine di offrire agli sviluppatori tutti gli strumenti volti a rendere ogni soluzione aziendale, un prodotto migliore sotto ogni punto di vista.

È esattamente secondo questa prospettiva che hanno avuto origine metodologie quali: Continuous Integration, Continuous Delivery e Continuous Deployment. Tre concetti molto interessanti e da non confondere assolutamente fra loro.

 

 

Continuous Integration

Continuous Integration (CI) o integrazione continua è una delle pratiche DevOps fondamentali, nonché una pratica di sviluppo volta all’integrazione e alla condivisione del codice tra gli sviluppatori.

In particolare, al fine di rendere la Continuous Integration una pratica efficace, gli sviluppatori integrano di frequente tutto il codice in un repository condiviso, ovvero in un ambiente che funge da sistema informativo in cui vengono gestiti tutti i metadati attraverso un insieme di tabelle relazionali.

Tale deposito virtuale offre numerosi vantaggi in termini di sicurezza, di controllo per l’accesso, di recupero degli errori e di gestione centralizzata di backup. Infatti, attraverso l’uso di un repository condiviso ogni sviluppatore può facilmente condividere una gran mole di dati in modo efficiente, così come può rapidamente aggiungere e gestire sottosistemi di dati che agiscono indipendentemente gli uni dagli altri.

In questo modo, una volta unito il codice tramite l’uso di un repository, sarà possibile eseguire la compilazione e la creazione di “pacchetti” da mettere sui server in modo completamente automatizzato al fine di verificare e testare l’intero progetto senza alcun intervento umano.

Lo scopo di questa fase di verifica automatica è esattamente quello di trasformare il codice sorgente in un artefatto, ovvero in un sottoprodotto che viene realizzato durante lo sviluppo software. In questo senso, sono artefatti il codice sorgente, la documentazione varia e tutto ciò che aiuta a descrivere la funzione, l’architettura e la progettazione del software.

Notiamo bene come il concetto di Continuous Integration risulta fondamentale in fase di progettazione in quanto, concentrandosi su strumenti di automazione, consente agli sviluppatori di integrare, condividere e testare continuamente il codice.

Tutto ciò permette non solo un notevole risparmio di tempo in fase di progettazione, quanto ne facilita anche il processo.

Una pratica nata intorno agli anni Novanta a supporto dell’integrazione e della condivisione delle migliori pratiche fra sviluppatori.

Seppur richiede specifiche competenze e tempo per impostare strumenti e pratiche di test avanzate e automatizzate, l’integrazione continua è una pratica di sviluppo che offre non pochi vantaggi per la realizzazione finale del software.

Integrazioni rapide e frequenti, aumento della comunicazione e della collaborazione fra team di sviluppo, rilevazione rapida ed efficace dei problemi: sono solo alcuni dei numerosi vantaggi che tale pratica mette a disposizione degli sviluppatori durante la programmazione di software moderni e all’avanguardia.

 

 

Continuous Delivery

Continuous Delivery (CD) o consegna continua è poi un’altra importante pratica dell’approccio DevOps.

Strettamente correlata con la Continuous Integration, la Continuous Delivery è una pratica di sviluppo software in cui, sulla base dei test automatizzati ottenuti tramite Continuous Integration, è possibile sviluppare e distribuire software di alta qualità in modo efficace, rapido e affidabile con un sovraccarico manuale ridotto al minimo.

In questo senso, Continuous Integration e Continuous Delivery sono parte integrante del processo di implementazione continua.

Infatti, mentre con l’integrazione continua si punta ad uno sviluppo agile attraverso la costante integrazione di blocchi di codice nei repository condivisi e tramite l’automatizzazione dei test di verifica, con la consegna continua si mette in atto una pratica che comprende la fase di rilascio del software finale.

La differenza fondamentale fra le due pratiche di sviluppo riguarda l’attività di automatizzazione. Se in una prima fase, e quindi nell’integrazione continua, l’attività di automatizzazione avviene sui test e sulle procedure di verifica del codice, in una seconda fase, ovvero nella consegna continua, tale attività si concentra sul processo di rilascio del software.

In questo modo, tramite Continuous Delivery è possibile attuare un processo in cui team di sviluppo producono software in brevi cicli e ne garantiscono il loro rilascio in modo affidabile in qualsiasi momento.

Dunque, una pratica che mira a costruire, testare e rilasciare software con maggiore velocità e frequenza, riducendo i costi e i tempi di rilascio.

Tuttavia, con la consegna continua i software, creati e pronti ad essere rilasciati, non saranno mai distribuiti senza una decisione manuale e quindi senza l’intervento umano.

 

 

Continuous Deployment

Continuous Deployment (CD) o distribuzione continua è, invece, una pratica di sviluppo software in cui le modifiche del codice vengono progettate automaticamente per un rilascio in produzione.

In questo senso, la distribuzione continua va oltre la consegna continua in quanto con questa pratica ogni modifica, una volta superate tutte le fasi di testing del codice, viene rilasciata automaticamente ai clienti.

Continuous Delivery e Continuous Deployment sono due concetti strettamente correlati e usati di frequente in modo intercambiabile in quanto entrambi prevedono l’automazione delle fasi successive alla costante integrazione di codice relative alla pratica di Continuous Integration.

Tuttavia, Continuous Delivery e Continuous Deployment sono usati distintamente allo scopo di indicare il diverso livello di automazione applicato.

Continuous Deployment è una pratica che implica l’automatizzazione di tutti i processi senza alcun intervento umano, portando una nuova versione del software direttamente nell’ambiente di produzione.

Pertanto, con distribuzione continua si intende la fase di sviluppo conclusiva di un flusso CI/CD.

Eppure, molto spesso la distribuzione continua appare rischiosa agli occhi di tante aziende in quanto non essendoci alcun blocco manuale, la distribuzione continua del software deve necessariamente fare affidamento su un’automazione dei test ben progettata.

Nonostante i rischi legati a tale pratica, la distribuzione continua presenta anche numerosi vantaggi.

Infatti, tramite Continuous Deployment non solo gli sviluppatori riducono i tempi di sviluppo per eventuali modiche e aggiornamenti, quanto aumentano di gran lunga l’affidabilità del software.

In questo modo, i team di sviluppo possono aggiungere nuove funzionalità al software in modo sicuro e rilasciarle automaticamente agli utenti, semplicemente scrivendo il codice e i relativi test.

 

 

Cos’è Jenkins?

Con l’avanzare dell’integrazione continua come pratica di sviluppo sempre più utilizzata da piccoli team di sviluppo fino alle grandi organizzazioni aziendali che eseguono internamente le loro complesse piattaforme, nel tempo si è rapidamente sviluppato un importante ecosistema di strumenti associati a tale pratica.

Fra i primi strumenti nati a supporto dell’integrazione continua, c’è Jenkins, un progetto open source tra i più utilizzati dagli sviluppatori.

Scritto in linguaggio Java, Jenkins è il principale server di automazione usato in fase di integrazione continua, il quale fornisce centinaia di plugin per supportare la costruzione, l’implementazione e l’automazione di qualsiasi progetto.

Difatti, Jenkins è stato pensato e programmato per supportare qualsiasi tipologia di progetto, dalle implementazioni su piccola scala fino ad implementazioni più complesse e articolate.

Quella di Jenkins è un’architettura ideata da una comunità di sviluppo molto ampia e attiva, per merito della quale sono, ad oggi, presenti un gran numero plugin caratterizzati da molte funzionalità moderne e di qualità.

Inoltre, negli ultimi anni Jenkins ha acquisito un nuovo linguaggio programmato per descrivere i flussi di lavoro di integrazione continua, anche noti come pipeline.

Tutto ciò consente agli sviluppatori non solo di creare moduli standard da riutilizzare anche per diversi progetti, ma soprattutto di dichiarare e descrivere il processo relativo alla compilazione e alla distribuzione del software.

 

 

Conclusioni

Continuous Integration, Continuous Delivery e Continuous Deployment sono tre pratiche di sviluppo che si concentrano sulla capacità di pianificare, sviluppare e distribuire i software in modo rapido, efficace e sicuro.

Ma in che modo gli sviluppatori possono utilizzare al meglio queste pratiche?

Integrazione continua, consegna continua e distribuzione continua sono pratiche di sviluppo che consentono agli sviluppatori di concentrarsi sulla scrittura del codice, tralasciando i processi di controllo, di verifica e di distribuzione manuale.

Tutto ciò risulta possibile grazie ad una serie di strumenti e di tecnologie di cui gli sviluppatori possono oggi beneficiare al fine di automatizzare ogni singola fase di sviluppo.

In questo modo, qualsiasi situazione potrà essere facilmente gestita in modo automatizzato dal sistema senza la necessità da parte del team di sviluppo di gestire azioni di modifica, di controllo e di aggiornamento del software.

Nel complesso, ogni pratica è un concetto in costante sviluppo, così come ogni progetto ancora in fase di progettazione necessita di essere pianificato sulla base dell’approccio che si intende avere sull’utente finale.

La distribuzione continua risulta, infatti, una pratica fondamentale al fine di ottenere in modo più rapido i feedback dagli utenti finali, così come permette di pianificarne di volta in volta le interazioni successive.

In questo senso, la distribuzione continua o implementazione continua si concentra a pieno sulla pratica dello sviluppo dinamico in quanto consente al ciclo di vita del progetto di cambiare rapidamente e in base alle sessioni di revisione.

Pertanto, seguire questa pratica di sviluppo garantisce cambiamenti fluidi e continuamente aggiornati in base allo stato del progetto in un determinato momento.

Tuttavia è l’integrazione continua che si pone come base sia per la consegna continua che per la distribuzione continua e a sua volta la consegna continua non trova la sua vera funzionalità senza la possibilità di distribuire e verificare continuamente il software in ambienti di produzione e di test.

Dunque, ogni pratica di sviluppo è a se stante e assume una rilevanza del tutto soggettiva, ma pur sempre correlata all’utilizzo delle altre pratiche e dei loro strumenti associati.