🥇Guida per principianti: creiamo un pipeline DevOps

Se sei un novizio in DevOps, dai un'occhiata a questa guida per costruire il tuo primo pipeline in cinque fasi.

DevOps è diventato la soluzione standard per risolvere processi di sviluppo software lenti, disconnessi o non funzionanti. Il problema è che, se sei un principiante in DevOps e non sai da dove cominciare, potresti mancare di comprensione di questi metodi. In questo articolo parleremo di cosa sia un pipeline DevOps, insieme a una guida per costruirne uno in cinque passi. Anche se questo tutorial non è esaustivo, dovrebbe fornirti una base per iniziare il tuo percorso e ampliare le tue conoscenze in futuro. Ma cominciamo con la storia.

Il mio viaggio nel DevOps

In passato ho lavorato nel team cloud di Citi Group, sviluppando un'applicazione web per l'Infrastructure-as-a-Service (IaaS) per la gestione dell'infrastruttura cloud di Citi, ma sono sempre stato interessato a come rendere il processo di sviluppo più efficiente e portare cambiamenti culturali positivi nel team di sviluppo. La risposta l'ho trovata in un libro raccomandato da Greg Lavender, il direttore tecnico di Citi per l'architettura e l'infrastruttura cloud. Il libro si intitola «Il Progetto Fenice» (Il Progetto Fenice), e in esso vengono spiegati i principi del DevOps, presentati come un romanzo.

Nella tabella sul retro del libro è mostrato quanto spesso le diverse aziende distribuiscono i loro sistemi in un ambiente di rilascio:

Amazon: 23.000 al giorno
Google: 5.500 al giorno
Netflix: 500 al giorno
Facebook: Una volta al giorno
Twitter: 3 volte a settimana
Azienda tipica: Una volta ogni 9 mesi

Come sono possibili le frequenze di Amazon, Google e Netflix? Tutto perché queste aziende hanno trovato il modo di creare una pipeline DevOps quasi perfetta.

Eravamo lontani da questo fino a quando non abbiamo implementato DevOps in Citi. All'epoca, nel mio team c'erano vari ambienti, ma il deployment sul server di sviluppo era completamente manuale. Tutti gli sviluppatori avevano accesso a un solo server di sviluppo basato su IBM WebSphere Application Server Community Edition. Il problema era che il server si spegneva ogni volta che più utenti tentavano di eseguire il deployment contemporaneamente, quindi gli sviluppatori dovevano informarsi reciprocamente delle loro intenzioni, il che era piuttosto doloroso. Inoltre, c'erano problemi con una copertura del codice a basso livello, processi di deployment manuali ingombranti e l'assenza di tracciabilità del codice deployato associato a un determinato task o storia utente.

Ho capito che era necessario agire e ho trovato un collega con cui condividere la stessa visione. Abbiamo deciso di collaborare per creare un primo pipeline DevOps: lui ha installato una macchina virtuale e un server applicativo Tomcat, mentre io lavoravo su Jenkins, integrando Atlassian Jira e BitBucket, e occupandomi della copertura dei test del codice. Questo progetto collaterale è stato molto successo: abbiamo quasi completamente automatizzato molti processi, raggiunto un'affidabilità del nostro server di sviluppo del quasi 100%, garantito monitoraggio e migliorato la copertura dei test del codice, e aggiunto la possibilità di collegare i rami in Git con le attività in Jira o i deployment. La maggior parte degli strumenti che abbiamo utilizzato per costruire la nostra pipeline DevOps erano open source.

Ora capisco quanto fosse semplice la nostra pipeline DevOps: non abbiamo usato estensioni come Jenkins files o Ansible. Tuttavia, questa pipeline semplice funzionava bene, forse grazie al principio di Pareto (noto anche come regola 80/20).

Introduzione al DevOps e alla pipeline CI/CD

Se chiedi a diverse persone: "Che cos'è il DevOps?", probabilmente riceverai risposte diverse. Il DevOps, come l'Agile, si è evoluto per comprendere molteplici discipline, ma la maggior parte delle persone concorda su alcuni aspetti: il DevOps è una pratica di sviluppo software o un ciclo di vita dello sviluppo software (SDLC) con al centro il cambiamento della cultura, in cui sviluppatori e non sviluppatori operano in un ambiente in cui:

Sono automatizzate operazioni che prima venivano svolte manualmente;
Ognuno fa ciò che sa fare meglio;
Il numero di implementazioni in un determinato intervallo di tempo aumenta; aumenta la capacità di lavoro;
Si migliora la flessibilità nello sviluppo.

Sebbene avere i giusti strumenti software non sia l'unica cosa necessaria per creare un ambiente DevOps, alcuni strumenti sono indispensabili. Uno strumento chiave è l'integrazione continua e il deployment continuo (CI/CD). In questa pipeline, gli ambienti hanno varie fasi (ad esempio, DEV, INT, TST, QA, UAT, STG, PROD), molte operazioni sono automatizzate e gli sviluppatori possono scrivere codice di alta qualità, ottenere flessibilità nello sviluppo e un'alta frequenza di deployment.

Questo articolo descrive un approccio a cinque fasi per la creazione di una pipeline DevOps, simile a quella mostrata nel diagramma seguente, utilizzando strumenti open source.

Passo 1: Metodi CI/CD

La prima cosa necessaria è uno strumento per CI/CD. Jenkins, uno strumento open source basato su Java e distribuito con licenza MIT, è il mezzo che ha reso popolare l'approccio DevOps ed è diventato lo standard de facto.

Cos'è Jenkins? Pensalo come un magico telecomando universale che può comunicare con vari servizi e strumenti, organizzandoli. Di per sé, uno strumento CI/CD come Jenkins è inutile, ma diventa più potente man mano che si connette a diversi strumenti e servizi.

Jenkins è solo uno dei tanti strumenti open source per CI/CD che puoi utilizzare per costruire un pipeline DevOps.

Jenkins: Creative Commons e MIT
Travis CI: MIT
CruiseControl: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU

Ecco come appaiono i processi DevOps con uno strumento CI/CD:

Hai uno strumento CI/CD in esecuzione sul tuo localhost, ma al momento puoi fare poco. Passiamo quindi alla fase successiva del viaggio nel mondo DevOps.

Passo 2: Gestione dei sistemi di controllo del codice sorgente

Il miglior (e forse il più semplice) modo per verificare che il tuo strumento CI/CD possa fare magie è integrarlo con uno strumento di controllo della versione (SCM). Perché hai bisogno del controllo del codice sorgente? Supponiamo che tu stia sviluppando un'applicazione. Ogni volta che crei un'app, stai programmando e non importa se usi Java, Python, C++, Go, Ruby, JavaScript o uno qualsiasi dei tantissimi linguaggi di programmazione. Il codice che scrivi si chiama codice sorgente. All'inizio, specialmente quando lavori da solo, probabilmente puoi mettere tutto in una directory locale. Ma quando il progetto cresce e inviti altre persone a collaborare, hai bisogno di un modo per prevenire conflitti mentre condividi efficacemente le modifiche. Hai anche bisogno di un modo per ripristinare versioni precedenti, perché creare backup e fare copia/incollo è ormai obsoleto. Hai bisogno di qualcosa di meglio per te e per i tuoi compagni di squadra.

È proprio qui che uno strumento di controllo del codice sorgente diventa praticamente fondamentale. Questo strumento salva il tuo codice nei repository, tiene traccia delle versioni e coordina il lavoro dei membri del progetto.

Sebbene esistano numerosi strumenti di controllo del codice sorgente, Git è lo standard, e questo è un dato di fatto. Ti consiglio vivamente di utilizzare Git, anche se, se lo desideri, ci sono altre opzioni open source.

Git: GPLv2 e LGPL v2.1
Subversion: Apache 2.0
Concurrent Versions System (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+

Ecco come appare una pipeline DevOps con l'aggiunta di strumenti di controllo del codice sorgente.

Uno strumento CI/CD può automatizzare i processi di verifica, acquisizione del codice sorgente e collaborazione tra i membri. Non sembra male? Ma come creare un'applicazione funzionante che miliardi di persone possano usare e apprezzare?

Passo 3: Creazione dello strumento di automazione della compilazione

Ottimo! Puoi controllare il codice e apportare modifiche al sistema di controllo del codice sorgente, oltre a invitare i tuoi amici a collaborare allo sviluppo. Ma non hai ancora creato un'applicazione. Per fare un'applicazione web, deve essere compilata e impacchettata in un formato di pacchetto distribuibile o eseguita come file eseguibile. (Tieni presente che un linguaggio di programmazione interpretato, come JavaScript o PHP, non richiede compilazione).

Utilizza uno strumento di automazione della compilazione. Indipendentemente dallo strumento di automazione della compilazione che decidi di utilizzare, tutti perseguono lo stesso obiettivo: raccogliere il codice sorgente in un formato desiderato e automatizzare il compito di pulizia, compilazione, test e distribuzione in un determinato ambiente. Gli strumenti di compilazione varieranno a seconda del tuo linguaggio di programmazione, ma ecco alcune opzioni comuni open source.

Nome
Licenza
Linguaggio di programmazione

Maven
Apache 2.0
Java

Ant
Apache 2.0
Java

Gradle
Apache 2.0
Java

Bazel
Apache 2.0
Java

Make
GNU
N/A

Grunt
MIT
JavaScript

Gulp
MIT
JavaScript

Buildr
Apache
Ruby

Rake
MIT
Ruby

A-A-P
GNU
Python

SCons
MIT
Python

BitBake
GPLv2
Python

Cake
MIT
C#

ASDF
Expat (MIT)
LISP

Cabal
BSD
Haskell

Ottimo! Puoi inserire i file di configurazione dello strumento di automazione della build nel sistema di gestione del codice sorgente e lasciare che il tuo strumento CI/CD componga tutto insieme.

Tutto bene, vero? Ma dove vuoi distribuire la tua applicazione?

Passo 4: Server per applicazioni web

Finora hai un file impacchettato, che può essere eseguibile o installabile. Affinché qualsiasi applicazione sia davvero utile, deve fornire qualche servizio o interfaccia, ma hai bisogno di un contenitore per ospitare la tua applicazione.

Il server per applicazioni web è proprio quel contenitore. Il server fornisce un ambiente in cui può essere definita la logica del pacchetto da distribuire. Inoltre, il server offre un'interfaccia e mette a disposizione servizi web, aprendo socket per il mondo esterno. Hai bisogno di un server HTTP, oltre a un ambiente (come una macchina virtuale) per la sua installazione. Per ora, supponiamo che tu lo scopra più avanti (anche se parlerò di contenitori più sotto).

Esistono diversi server per applicazioni web open source.

Nome
Licenza
Linguaggio di programmazione

Tomcat
Apache 2.0
Java

Jetty
Apache 2.0
Java

WildFly
GNU Lesser Public
Java

GlassFish
CDDL & GNU Less Public
Java

Django
3-Clause BSD
Python

Tornado
Apache 2.0
Python

Gunicorn
MIT
Python

Python
MIT
Python

Rails
MIT
Ruby

Node.js
MIT
Javascript

Il tuo pipeline DevOps è quasi pronto per l'uso. Ottimo lavoro!

Anche se puoi fermarti qui e gestire l'integrazione da solo, la qualità del codice è fondamentale per uno sviluppatore di applicazioni e vale la pena prendersene cura.

Passo 5: Copertura dei test del codice

Implementare i test può essere un'ulteriore richiesta complessa, ma gli sviluppatori devono rilevare eventuali errori nell'applicazione in una fase iniziale e migliorare la qualità del codice per garantire che gli utenti finali siano soddisfatti. Fortunatamente, esistono molti strumenti open source per testare il tuo codice e fornire raccomandazioni per migliorare la sua qualità. Ancora meglio, la maggior parte degli strumenti CI/CD può integrarsi con questi strumenti e automatizzare il processo.

Il testing del codice consiste in due parti: framework di testing del codice che aiutano a scrivere e eseguire test, e strumenti di suggerimento che aiutano a migliorare la qualità del codice.

Sistemi di testing del codice

Nome
Licenza
Linguaggio di programmazione

JUnit
Eclipse Public License
Java

EasyMock
Apache
Java

Mockito
MIT
Java

PowerMock
Apache 2.0
Java

Pytest
MIT
Python

Hypothesis
Mozilla
Python

Tox
MIT
Python

Sistemi di raccomandazione per migliorare il codice

Nome
Licenza
Linguaggio di programmazione

Cobertura
GNU
Java

CodeCover
Eclipse Public (EPL)
Java

Coverage.py
Apache 2.0
Python

Emma
Common Public License
Java

JaCoCo
Eclipse Public License
Java

Hypothesis
Mozilla
Python

Tox
MIT
Python

Jasmine
MIT
JavaScript

Karma
MIT
JavaScript

Mocha
MIT
JavaScript

Jest
MIT
JavaScript

Nota che la maggior parte degli strumenti e dei framework menzionati sopra sono scritti per Java, Python e JavaScript, mentre C++ e C# sono linguaggi di programmazione proprietari (sebbene GCC abbia un codice sorgente aperto).

Ora che hai implementato strumenti di copertura del codice attraverso dei test, il tuo pipeline DevOps dovrebbe apparire simile al diagramma mostrato all'inizio di questa guida.

Passi aggiuntivi

Container

Come ho già detto, puoi ospitare il tuo server su una macchina virtuale o su un server, ma i contenitori sono una soluzione popolare.

Cosa sono i contenitori? In breve, una macchina virtuale richiede un ingente volume di memoria del sistema operativo, superiore alla dimensione dell'applicazione, mentre un contenitore ha bisogno solo di alcune librerie e configurazioni per eseguire l'applicazione. È evidente che le macchine virtuali hanno ancora applicazioni importanti, ma un contenitore è una soluzione leggera per l'hosting di applicazioni, inclusi i server di applicazione.

Sebbene ci siano altre opzioni di container, i più popolari sono Docker e Kubernetes.

Docker: Apache 2.0
Kubernetes: Apache 2.0

Strumenti di automazione intermedi

Il nostro pipeline DevOps è principalmente focalizzato sulla co-creazione e sul disegno di applicazioni, ma ci sono molte altre cose che possono essere fatte con gli strumenti DevOps. Una di queste è l'utilizzo di strumenti Infrastructure as Code (IaC), noti anche come strumenti di automazione intermedi. Questi strumenti aiutano ad automatizzare l'installazione, la gestione e altre attività per il software intermedio. Ad esempio, uno strumento di automazione può estrarre applicazioni come server di applicazioni, database e strumenti di monitoraggio, con configurazioni appropriate e distribuirle su un server di applicazioni.

Ecco alcuni strumenti di automazione intermedi open source:

Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache o GPL