Nei precedenti blog post abbiamo approfondito concetti come Metodologia DevOps, Cloud, Security e pratiche e tool collegati, spiegando come la Digital Transformation abbia influenzato e modificato radicalmente l’approccio aziendale a queste tre aree nell’ottica di uno sviluppo applicativo sempre più Agile e flessibile.
Ma come interagiscono tra loro i diversi DevOps Tools? Qual è il modello di riferimento a cui un’azienda dovrebbe aspirare?
Analizziamo insieme quella che noi riteniamo la Reference Architecture ideale, ovvero lo standard che, sulla base della nostra esperienza, riteniamo ottimale per far interagire i differenti DevOps Tools per implementare un ciclo di vita del software automatizzato, rapido, efficace e sicuro.
L’architettura a cui ci riferiamo, nello specifico, è la seguente:
Lo schema può sembrare un po’ complesso a una prima occhiata, ma possiamo garantire che, una volta compresa la logica che ne sta alla base, diventerà il vostro punto di riferimento.
Partiamo dicendo che, prima di far partire qualsiasi processo, la cosa migliore da fare è definire quali sono gli standard, ovvero quelle procedure e norme di base alle quali fare riferimento per la gestione delle attività.
Immaginiamo quindi che la tua azienda, o nello specifico il tuo reparto IT, si trovi ad esempio a dover:
- Creare un nuovo server
- Far partire dei nuovi container con all’interno degli applicativi
- Redigere ed archiviare della documentazione
Per agire in ottica di ottimizzazione, automazione ed efficienza, bisogna individuare delle azioni standard e univoche da intraprendere ogni qualvolta si intenda dare inizio a queste tipologie di processi. In questo caso l’azione sarà essere sempre la stessa: faccio un commit e salvo il codice su GitHub, la più nota e diffusa piattaforma per il code hosting e lo sviluppo collaborativo basata sul DVCS (Distributed Version Control System) Git.
Sempre in quest’ottica, dopo aver ricevuto l’input, il processo dovrà essere definito e indirizzato attraverso un tool “centrale” che definisca la “logica” e comunichi al sistema come procedere. Questo passaggio dovrà quindi coinvolgere tutte le fasi di sviluppo del software nello stile DevOps, dalla scrittura alla configurazione, dalle fasi di test a quelle di rilascio e distribuzione. Il tool che noi abbiamo identificato per questo ruolo chiave è Jenkins.
All’interno di Jenkins si andranno quindi ad inserire le cosiddette pipeline che vanno a definire il processo, ossia l’insieme delle componenti software collegate tra loro a cascata, tali per cui il risultato prodotto da uno degli elementi (output) sia l'ingresso di quello immediatamente successivo (input).
Abbiamo quindi citato i due principali abilitatori DevOps, che fanno in modo che il processo venga avviato e indirizzato in modo corretto e standardizzato, che necessitano però di un approfondimento specifico al fine di comprendere come essi agiscono e quali sono le tecnologie alla base di questi.
GITHUB
GitHub, software che abbiamo definito sopra, identificabile a metà strada tra un social network e un repository di file, è usato sia per progetti Open Source che privati.
Lo possiamo utilizzare per salvare tutta la documentazione tecnica, il codice applicativo o i file di definizione e configurazione dell’infrastruttura (quindi non solo software inteso come applicazione), i playbook di Ansible, le pipeline, il tutto suddiviso in diversi repository a seconda delle aree coinvolte.
In riferimento ai flussi di sviluppo, GitHub si basa su un processo detto GitHub Flow: questo sistema permette di tenere traccia della storia del software in maniera chiara e leggibile, che facilita lo sviluppo e permette ai team di suddividere gli sforzi sulle diverse fasi di implementazione, correzione, pulizia, rilascio, concedendo a ciascuna di esse adeguati spazi all’interno del repository e adeguate tempistiche all’interno del flusso. Tutto ciò viene costantemente monitorato, permettendo quindi di intervenire rapidamente sulle eventuali criticità a qualunque livello del processo.
Ciò che sta alla base di questo tool è il concetto di TEAM, ovvero il suo essere estremamente collaborativo durante la fase di revisione del codice, vantando numerosissime integrazioni native con altri tool. GitHub permette di mantenere l’intero processo all’interno di un’unica piattaforma, consentendo agli sviluppatori di lavorare con gli strumenti che preferiscono, compresi quelli per la continuous integration e centinaia di app e servizi di terze parti.
Un’altra funzionalità importante che noi utilizziamo molto è quella di Project Management, spesso poco sfruttata, nella quale si ha una Kanban Board collegata con le varie issue o pull request aperte che possono essere trasversali tra i vari progetti e ognuna delle quali è organizzata in task assegnabili ad uno o più membri del team. Durante questi passaggi è possibile lasciare commenti, allegare file o immagini creando quindi uno storico completo e organizzato, il tutto in una logica Wiki che permette grande collaborazione tra i vari attori. Quest’ultimo punto è importantissimo per noi che sposiamo la vision DevOps e Open Source, ed è una delle caratteristiche principali per cui proponiamo GitHub come soluzione ottimale per i nostri clienti. Per le grandi realtà, in particolare, suggeriamo GitHub Enterprise, ossia la versione on premise di GitHub, fornita come virtual appliance eseguibile in cloud o su tutti i principali hypervisor.
Una delle più recenti e importanti novità di GitHub è rappresentata, oltre che dall’acquisizione da parte di Microsoft, dalle ACTION. Si possono combinare fino a 100 GitHub Action per creare workflow complessi attraverso azioni definite nel repository e sono tutte altamente personalizzabili. Ad oggi questa funzionalità è disponibile solo in versione Limited Public Beta.
JENKINS
È il più famoso sistema per la Continuous Integration e Continuous Delivery che permette di automatizzare il ciclo di vita di application delivery incrementando la produttività e aumentando la qualità delle applicazioni. Si basa su un’architettura di tipo master-slave, è molto semplice da installare e da configurare.
Anche qui esiste la corrispondente versione Enterprise, ovvero CloudBees Core, che:
- grazie alle funzionalità di Continuous Delivery on premise e in cloud soddisfa specifiche esigenze Enterprise di sicurezza, scalabilità e gestibilità
- è integrabile con OpenShift e Kubernetes
- include la funzionalità “Team” come GitHub
- ha funzionalità di analytics, monitoring ed alerting avanzati
- è molto flessibile
- funziona anche con applicazioni non containerizzate
- ha un’interfaccia web molto user-friendly.
Come spiegato sopra, CloudBees è il tool centrale che coinvolge tutte le fasi di sviluppo del software in ottica DevOps. Una delle ragioni principali per cui è la soluzione più utilizzata è la quantità di plugin per l’interazione con altri Tool (più di 1.400 ad oggi).
Durante il DevOps World | Jenkins World di Settembre 2018, CloudBees ha annunciato inoltre l’attuale offerta di soluzioni tecnologiche che include:
- CloudBees DevOptics, strumento di analisi e monitoraggio delle performance DevOps
- CloudBees CodeShip, versione as a Service di CloudBees Core
- CloudBees Starter Kit, un bundle per i team che vogliono iniziare ad usare CloudBees: esso dà accesso a CloudBees Core e CloudBees DevOptics fornendo quindi funzionalità aziendali come l'automazione della pipeline, il monitoraggio delle prestazioni DevOps e la mappatura del flusso del valore in tempo reale per visualizzare le diverse fasi del processo di delivery del software. Questo “kit” include anche una formazione virtuale e un quickstart remoto, che fornisce ai nuovi team l’installazione e la configurazione di CloudBees Core e CloudBees DevOptics con una panoramica generale di gestione.
- CloudBees Apps, una sorta di “app store” dove la community rilascia continuamente integrazioni “prefabbricate” che si comportano esattamente come un plugin di Jenkins, ad esempio se decido di scaricare il plugin per collegarmi a Git e allo stesso modo mi scarico la applicazione che mi permette di fare Continuous Integration su Openshift prendendo i dati da Github, il tutto con un’integrazione già pronta.
Quanto abbiamo trattato è solamente la base della reference architecture, che è il nostro “ideale” di Architettura DevOps e coinvolge quindi ulteriori passaggi e tecnologie come:
- i container, qualora l’applicativo che si vuole sviluppare sia basato su tale tecnologia o si desideri rendere gli ambienti di compilazione ed esecuzione completamente riproducibili e definiti tramite codice;
- soluzioni di configuration management, qualora ci si basi su un’infrastruttura classica virtuale che necessiterà quindi di un’astrazione e di un’automazione dei processi di gestione;
- big data management & analytics per l’analisi dei dati generati dai tool e i processi e l’utilizzo degli stessi per prevenire errori e anomalie;
- il machine learning che consente di identificare le informazioni rilevanti all’interno di enormi moli di dati e correlarle tra loro, utilizzabili per semplificare ed automatizzare i task.
Seguici nei prossimi Blog post, dove andremo ad approfondire nello specifico queste tecnologie, correlandole al flusso di sviluppo e all’intera architettura e scoprendo come seguendo questo schema, il processo diventi talmente preciso e controllato da ridurre le probabilità di errore al minimo.
Vuoi saperne di più su quelli che noi riteniamo i migliori DevOps Tools per la Digital Transformation? Scarica la nostra Guida Gratuita:
