Differenza tra metodologia DevOps e Integrazione continua

Differenza tra metodologia DevOps e Integrazione continua

DevOps

Il termine DevOps nasce dalla contrazione di due termini, Development ed Operations. Concerne, infatti, una stretta correlazione tra la fase “Dev”, quella di pianificazione e sviluppo, ed “Ops”, quella dedicata al rilascio e, più in generale, al ciclo di vita del software. Tale correlazione mira a rendere lo sviluppo ed i rilasci di software molto più rapidi e produttivi.

L’approccio DevOps è iniziato ad essere sempre più applicato nelle aziende, dove i team dedicati allo sviluppo di codice e quelli dedicati alla produzione di software non agiscono più separatamente, ma fanno parte di un’unica unità che segue l’intero ciclo di vita dell’applicazione, principalmente grazie all’automatizzazione di gran parte dei processi.

I vantaggi

  1. Velocità: i processi sono molto più snelli ed agili, e permettono di tenere il passo delle sempre più esigenti richieste di mercato.
  2. Automatizzazione dei processi: questa diminuisce notevolmente la complessità di molte operazioni critiche durante un rilascio, come ad esempio build, test e deploy.
  3. Efficienza: è una diretta conseguenza dei primi due punti. Grazie alla rapidità di sviluppo e all’automatizzazione, lo sviluppo software risulta di gran lunga più efficiente. Il rilascio di nuove release avviene in maniera immediata, rendendo possibile la frequente pubblicazione di aggiornamenti.
  4. Scalabilità: l’approccio in questione offre dei metodi per gestire sistemi e processi su qualsiasi scala. Sfruttando la stessa infrastruttura sarà possibile adattare le risorse allocate in tempo reale “on demand”, in base al numero di richieste ricevute.
  5. Affidabilità: grazie all’integrazione continua, sulla quale approfondirò più avanti, è possibile verificare costantemente la qualità degli aggiornamenti e dei sistemi. È possibile monitorare continuamente le prestazioni tramite dei sistemi di log.
  6. Collaborazione: interazione continua tra sviluppatori e sistemisti, i quali si confronteranno su tutte le fasi del ciclo di vita del software.
  7. Sicurezza: la velocità di sviluppo non va assolutamente a discapito della sicurezza. La sicurezza deve diventare parte integrante di tutte le fasi del ciclo di vita, dal principio alla fine dello sviluppo. Alcune volte, proprio per sottolineare l’importanza della sicurezza, anziché DevOps qualcuno usa il termine “DevSecOps” (Development, Security, Operations).

Principi della metodologia devops

Lo sviluppo DevOps si fonda su alcuni principi riguardanti sia il design che il rilascio di applicazioni.

Innanzitutto, riferiamoci all’architettura del software: come tratterò ampiamente più avanti, le classiche architetture monolitiche non si prestano assolutamente allo sviluppo DevOps. Seguendo il famoso paradigma informatico “divide et impera” per usufruire dei vantaggi di questa metodologia occorre partizionare le architetture, cercando di crearne una che offra le stesse funzionalità dell’applicazione monolitica, mettendo però a disposizione molteplici servizi indipendenti. Solitamente si tratta di porzioni di codice di piccole dimensioni, atte a svolgere un singolo compito: in quest’ultimo caso non si parla di servizi, ma di microservizi. “Ogni microservizio esegue il proprio processo e comunica con gli altri servizi tramite un’interfaccia predefinita utilizzando un mezzo con impatto ridotto sulle prestazioni, solitamente una API (Application Programming Interface) basata su http”.

Qualsiasi applicazione deve avere un sistema che ospita il proprio codice, un’infrastruttura sulla quale l’applicazione viene installata e resa disponibile. L’infrastruttura che meglio sposa i principi DevOps è la cosiddetta “infrastruttura come codice”. “Si tratta di una prassi secondo cui provisioning e gestione dell’infrastruttura avvengono tramite metodologie di sviluppo di software e codice. Questo tipo di infrastruttura favorisce il controllo di versione e l’integrazione continua”.

Il concetto di “Integrazione Continua” (dal termine inglese Continuous Integration) si basa invece sul rilascio continuo di codice, che va appunto ad integrare tempestivamente quanto già rilasciato.

Infine, un altro aspetto importante è quello del mantenimento del codice. Lo sviluppo DevOps mette a disposizione dei sistemi di registrazione e consultazione di log, indispensabili per scovare reattivamente errori o imperfezioni nel codice e rilasciare le opportune modifiche.

Differenza tra metodologia DevOps e Integrazione continua

Integrazione continua

Per Integrazione Continua si intende un metodo di sviluppo che mira a rilasciare continuamente nuove versioni del Software, atte a correggere tempestivamente eventuali errori nel codice ed a favorire la rapidità di pubblicazione di nuovi aggiornamenti.

È una pratica ad oggi molto comune all’interno di Team con diversi sviluppatori che lavorano sullo stesso progetto, uno scenario ormai molto comune. Sarebbe ovviamente molto dispendioso per uno sviluppatore apportare delle modifiche ad un progetto tenendo in considerazione eventuali altre modifiche effettuate da altri. È quindi indispensabile contestualmente alla fase di modifica preoccuparsi anche del rilascio, per poter mettere a disposizione di un altro membro del Team sempre una versione aggiornata.

L’integrazione continua avviene grazie all’automatizzazione delle fasi di build, test e deploy, che abbatte drasticamente i tempi necessari per effettuare un rilascio.

Per applicare il metodo di Integrazione continua è necessario disporre di un repository centralizzato dove il software viene di volta in volta rilasciato, e di un sistema di versioning che permetta di riconoscere le diverse versioni del software dopo i vari rilasci.

Ad ogni rilascio sul repository il software può essere sottoposto a dei test automatizzati.

Il corretto utilizzo di un modello ad Integrazione Continua porta molti dei vantaggi comuni alla metodologia DevOps, ossia:

  • Velocità nel rilascio di aggiornamenti (bux fix, nuove funzionalità, ecc.).
  • Identificazione di errori o debolezze del codice a monte del rilascio (grazie ai test automatici a cui si sottopone la nuova versione sviluppata).
  • Maggiore produttività.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *