In precedenza abbiamo sul Continuous Integration (CI). Proseguiamo con il Continuous Delivery. Si tratta di un insieme di tecniche di sviluppo software. Aiuta a garantire che il codice sia pronto per il deployment.
/ Pixabay / /
Storia
L'espressione continuous delivery è stata vista per la prima volta nel del 2001, all'inizio dell'elenco dei principi fondamentali: «La priorità è soddisfare le esigenze del cliente attraverso la fornitura continua di software aggiornato».
Nel 2010, Jez Humble e David Farley hanno pubblicato sul Continuous Delivery. Secondo gli autori, il CD integra l'approccio e consente di semplificare la preparazione del codice per il deployment.
Dopo la pubblicazione del libro, l'approccio ha guadagnato popolarità e in pochi anni è diventato praticamente consueto. Secondo , condotto tra oltre 600 sviluppatori e IT manager nel 2014, il 97% dei dirigenti tecnici e l'84% dei programmatori erano a conoscenza del Continuous Delivery.
Attualmente, questo approccio rimane uno dei più popolari. Secondo uno studio del 2018, a cui hanno partecipato membri della comunità IT, DevOps e Jenkins Community, la metà dei più di mille intervistati.
Come funziona il Continuous Delivery
Il Baseline CD rappresenta la prontezza del codice per il deployment. Per raggiungere questo obiettivo si utilizza l'automazione del processo di preparazione del software per il rilascio. Questo deve essere standard per diversi ambienti di sviluppo, il che aiuta a identificare più rapidamente i punti deboli e ad ottimizzarli. Ad esempio, accelerando i test.
Un esempio del processo di Continuous Delivery si presenta nel seguente modo:
Se l'automazione delle prime due fasi è gestita dal paradigma del Continuous Integration, per le successive due abbiamo il Continuous Delivery. La stabilità del processo è garantita anche grazie ai . Questi monitorano le modifiche nell'infrastruttura, nei database e nelle dipendenze. Il deployment stesso può essere automatizzato oppure effettuato manualmente.
Il processo deve soddisfare i seguenti requisiti:
- Disponibilità delle informazioni sulla prontezza per il rilascio in ambiente di production e prontezza per un rilascio immediato (gli strumenti CD testano il codice e consentono di valutare l'effetto delle modifiche nel rilascio).
- Responsabilità generale per il prodotto finale. Il team prodotto — manager, sviluppatori, tester — si concentra sul risultato, non solo sulla propria area di responsabilità (il risultato è un rilascio funzionante, accessibile agli utenti del prodotto).
In CD si applica solitamente , e per raccogliere feedback dai clienti — il principio . Una nuova funzionalità viene prima rilasciata a un piccolo segmento di utenti: la loro esperienza con il prodotto aiuta a trovare problemi e bug che non sono stati notati durante i test interni.
Qual è il vantaggio
Continuous Delivery aiuta a semplificare il deploy del codice, il che influisce positivamente sulla produttività e riduce la possibilità di burnout emotivo dei dipendenti. Alla fine, riduce anche i costi complessivi dello sviluppo. Ad esempio, CD ha aiutato uno dei team HP questi costi del 40%.
Inoltre — secondo uno studio del 2016 (pagina 28 ) — le aziende che hanno implementato CD risolvono i problemi di sicurezza informatica il 50% più rapidamente rispetto a quelle che non usano l'approccio. In una certa misura, questa differenza può essere spiegata dal lavoro degli strumenti di automazione del processo.
Un ulteriore vantaggio è l'accelerazione del rilascio delle versioni. Nel nostro studio di sviluppo finlandese, il delivery continuo ad aumentare la velocità di compilazione del codice del 25%.
Difficoltà potenziali
Il problema principale è la necessità di ristrutturare i processi abituali. Per mostrare i benefici del nuovo approccio, è consigliabile passare al CD gradualmente, iniziando dalle applicazioni meno onerose.
Il secondo potenziale problema è il gran numero di rami di codice. Una conseguenza della "diramazione" sono i frequenti conflitti e la perdita di tempo prezioso. Una possibile soluzione è il .
In alcune aziende, le principali difficoltà si riscontrano nei test, che richiedono troppo tempo. I risultati dei test spesso richiedono un'analisi manuale, ma una possibile soluzione potrebbe essere la parallelizzazione dei test nelle prime fasi di implementazione del CD.
È anche necessario formare il personale nell'uso dei nuovi strumenti: un'istruzione preliminare farà risparmiare energia e tempo agli sviluppatori.
/ Flickr / /
Strumenti
Ecco alcuni strumenti open source per la Continuous Delivery:
- — server per la consegna continua su Java e JRuby on Rails. Consente di controllare l'intero processo di distribuzione dell'applicazione: build—test—release. Lo strumento è distribuito con licenza Apache 2.0. Sul sito ufficiale puoi trovare .
- — framework per creare script che automatizzano il deployment di applicazioni in Ruby, Java o PHP. Capistrano può eseguire comandi su una macchina remota collegandosi a essa tramite SSH. Funziona con altri strumenti di integrazione e distribuzione continua, come il server CI Integrity.
- — strumento multipiattaforma che automatizza l'intero ciclo di sviluppo delle applicazioni. Gradle lavora con Java, Python, C/C++, Scala e altri. C'è integrazione con Eclipse, IntelliJ e Jenkins.
- — piattaforma per CD in Go. Drone può essere implementato on-premise o nel cloud. Lo strumento è costruito su base container e utilizza file YAML per gestirli.
- — piattaforma per la distribuzione continua del codice in sistemi multi-cloud. Sviluppato in Netflix, un ruolo significativo nello sviluppo dello strumento è stato svolto dagli ingegneri di Google. Puoi trovare la guida all'installazione .
Cosa leggere sul nostro blog aziendale:
Fonte: habr.com
