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

Il DevOps è diventato la soluzione standard per correggere processi di sviluppo software lenti, disconnessi o malfunzionanti. Il problema è che, se sei un principiante nel DevOps e non sai da dove cominciare, potresti non avere una comprensione di questi metodi. In questo articolo parlerò della definizione di un pipeline DevOps e fornirò una guida alla sua creazione in cinque passi. Anche se questa guida non è esaustiva, dovrebbe darti una base per iniziare il tuo percorso e ampliare le tue conoscenze in futuro. Ma iniziamo con la storia.
Il mio viaggio nel DevOps
In passato ho lavorato nel team cloud della Citi Group, sviluppando un'app web Infrastructure-as-a-Service (IaaS) per gestire l'infrastruttura cloud di Citi, ma sono sempre stato interessato a come rendere il processo di sviluppo più efficiente e a portare cambiamenti culturali positivi nel team di sviluppo. La risposta l'ho trovata in un libro raccomandato da Greg Lavender, Chief Technology Officer di Citi per l'architettura cloud e l'infrastruttura. Il libro si intitolava "The Phoenix Project", e spiega i principi del DevOps, presentandosi come un romanzo.
Nella tabella sul retro del libro viene mostrato con quale frequenza diverse aziende distribuiscono i loro sistemi in ambienti 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 un modo per creare quasi un pipeline DevOps ideale.
Eravamo lontani da questo fino a quando non abbiamo implementato DevOps in Citi. All'epoca nella mia squadra c'erano diversi ambienti, ma il deployment sul server di sviluppo era completamente manuale. Tutti gli sviluppatori avevano accesso solo a un 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 avvisarsi a vicenda delle proprie intenzioni, il che era piuttosto frustrante. Inoltre, c'erano problemi con la copertura del codice a basso livello, i processi ingombranti del deployment manuale e l'assenza della possibilità di tracciare il deployment del codice collegato a un compito specifico o a una storia utente.
Ho capito che dovevo fare qualcosa e ho trovato un collega con la mia stessa visione. Abbiamo deciso di collaborare per creare il nostro primo pipeline DevOps: lui ha installato una macchina virtuale e un server applicativo Tomcat, mentre io lavoravo su Jenkins, integravo Atlassian Jira e BitBucket e mi occupavo della copertura del codice. Questo progetto secondario è stato molto fruttuoso: abbiamo automatizzato quasi completamente molti processi, raggiunto praticamente il 100% di operatività del nostro server di sviluppo, garantito tracciabilità e migliorato la copertura del codice, oltre ad aver aggiunto la possibilità di collegare i branch in Git con i compiti in Jira o con il 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 utilizzato estensioni come Jenkins files o Ansible. Tuttavia, questa semplice pipeline funzionava bene, forse grazie al principio di Pareto (noto anche come regola 80/20).
Una breve introduzione a DevOps e alla pipeline CI/CD
Se chiedi a diverse persone: «Cos'è DevOps?», probabilmente riceverai diverse risposte. DevOps, proprio come Agile, si è evoluto per comprendere molte discipline diverse, ma la maggior parte delle persone sarà d'accordo su alcune cose: DevOps è una pratica di sviluppo software o un ciclo di vita dello sviluppo software (SDLC), il cui principio centrale è il cambiamento della cultura in cui sviluppatori e non sviluppatori esistono in un ambiente in cui:
Le operazioni che una volta venivano eseguite manualmente sono automatizzate;
Ognuno fa ciò in cui è migliore;
Il numero di implementazioni in un dato intervallo di tempo aumenta; Aumenta la capacità;
Aumenta la flessibilità nello sviluppo.
Sebbene avere gli strumenti software giusti non sia l'unica cosa necessaria per creare un ambiente DevOps, alcuni strumenti sono essenziali. Uno strumento chiave è l'integrazione continua e il deployment continuo (CI/CD). In questo pipeline, l'ambiente ha diverse 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 distribuzioni.
Questo articolo descrive un approccio a cinque fasi per creare un pipeline DevOps, simile a quello illustrato nel diagramma seguente, utilizzando strumenti open source.
Passo 1: Metodi CI/CD
La prima cosa di cui hai bisogno è uno strumento per CI/CD. Jenkins, uno strumento open source basato su Java e distribuito con licenza MIT, è il mezzo che ha reso popolare la direzione DevOps ed è diventato lo standard di fatto.
Ma cos'è Jenkins? Consideralo come un telecomando universale magico che può comunicare con vari servizi e strumenti e metterli in ordine. Da solo, uno strumento CI/CD come Jenkins è inutile, ma diventa più potente man mano che si collega a vari 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 lo strumento CI/CD:

Hai uno strumento CI/CD in esecuzione sul tuo localhost, ma per il momento puoi fare poco. Passiamo alla fase successiva del viaggio nel mondo DevOps.
Passo 2: Gestione dei sistemi di controllo del codice sorgente
Il modo migliore (e forse più semplice) per verificare che il tuo strumento CI/CD possa fare magie è integrarsi con uno strumento di controllo del codice sorgente (SCM). Perché hai bisogno del controllo del codice sorgente? Supponiamo che tu stia sviluppando un'applicazione. Ogni volta che crei un'applicazione, programmi, indipendentemente dal fatto che tu stia utilizzando Java, Python, C++, Go, Ruby, JavaScript o uno dei miliardi di linguaggi di programmazione. Il codice che scrivi è chiamato codice sorgente. All'inizio, specialmente quando lavori da solo, è probabile che tu possa mettere tutto in una directory locale. Ma quando il progetto cresce e inviti altre persone a collaborare, hai bisogno di un modo per evitare conflitti durante uno scambio efficace delle modifiche. Hai anche bisogno di un modo per ripristinare versioni precedenti, perché fare backup e copiare/incollare in esse è ormai obsoleto. Hai bisogno di qualcosa di meglio.
È qui che uno strumento di controllo del codice sorgente diventa praticamente indispensabile. Questo strumento salva il tuo codice nei repository, tiene traccia delle versioni e coordina il lavoro dei partecipanti al progetto.
Sebbene esistano molti strumenti di controllo del codice sorgente, Git è lo standard, e questo è vero. Ti consiglio vivamente di utilizzare Git, anche se, se vuoi, 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 un pipeline DevOps con l'aggiunta di strumenti di controllo del codice sorgente.

Lo strumento CI/CD può automatizzare i processi di verifica, recupero del codice sorgente e collaborazione tra i membri. Non male? Ma come trasformarlo in un'applicazione funzionante, in modo che miliardi di persone possano utilizzarla e apprezzarla?
Passo 3: Creazione di uno strumento di automazione della build
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 creare un'applicazione web, deve essere compilata e impacchettata in un formato di pacchetto distribuibile o eseguita come file eseguibile. (Nota che un linguaggio di programmazione interpretato, come JavaScript o PHP, non necessita di compilazione).
Utilizza uno strumento di automazione della build. Indipendentemente dallo strumento di automazione della build che decidi di utilizzare, tutti perseguono lo stesso obiettivo: compilare il codice sorgente in un formato desiderato e automatizzare il compito di pulizia, compilazione, test e distribuzione in un ambiente specifico. Gli strumenti di build 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
Fantastico! Puoi inserire i file di configurazione dello strumento di automazione della build nel sistema di gestione del codice sorgente e permettere al tuo strumento CI/CD di assemblare tutto insieme.

Tutto bene, vero? Ma dove distribuire la tua applicazione?
Passo 4: Server per applicazioni web
Finora hai un file impacchettato, che può essere sia eseguibile che installabile. Affinché qualsiasi applicazione sia veramente utile, deve fornire qualche servizio o interfaccia, ma hai bisogno di un contenitore per ospitare la tua applicazione.
Un server per applicazioni web è proprio quel contenitore. Fornisce un ambiente in cui può essere definita la logica del pacchetto distribuito. Il server fornisce anche un'interfaccia e offre servizi web, aprendo socket al mondo esterno. Hai bisogno di un server HTTP, oltre a un certo ambiente (ad esempio, una macchina virtuale) per la sua installazione. Nel frattempo, supponiamo che tu ne sappia di più in seguito (anche se di seguito parlerò dei contenitori).
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 è un aspetto fondamentale per un sviluppatore di applicazioni, e su questo bisogna prestare attenzione.
Passo 5: Copertura dei test del codice
L'implementazione dei test può rappresentare un ulteriore impegno, ma gli sviluppatori devono rilevare eventuali errori nell'applicazione nelle fasi iniziali e migliorare la qualità del codice per garantire che gli utenti finali siano soddisfatti. Fortunatamente, esistono numerosi strumenti open source per testare il tuo codice e generare suggerimenti per migliorare la sua qualità. Anche meglio, la maggior parte degli strumenti CI/CD può integrarsi con questi strumenti e automatizzare il processo.
Il testing del codice si compone di due parti: framework di testing del codice, che aiutano a scrivere e eseguire i test, e strumenti per generare suggerimenti, 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 framework menzionati sopra sono scritti per Java, Python e JavaScript, poiché C++ e C# sono linguaggi di programmazione proprietari (anche se GCC è open source).
Ora che hai implementato gli strumenti di copertura del codice testato, il tuo pipeline DevOps dovrebbe assomigliare al diagramma mostrato all'inizio di questa guida.
Ulteriori passi
Contenitori
Come ho già detto, puoi ospitare il tuo server su una macchina virtuale o un server, ma i container sono una soluzione popolare.
Cosa sono i container? In breve, una macchina virtuale ha bisogno di una grande quantità di memoria di sistema operativo, superiore alla dimensione dell'applicazione, mentre un container ha bisogno solo di alcune librerie e configurazioni per eseguire l'applicazione. È chiaro che le macchine virtuali hanno ancora applicazioni importanti, ma il container è una soluzione leggera per ospitare l'applicazione, incluso il server delle applicazioni.
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 intermedia
Il nostro pipeline DevOps è principalmente orientato alla co-creazione e distribuzione di applicazioni, ma esistono molte altre cose che si possono fare con gli strumenti DevOps. Uno di questi è l'uso di strumenti Infrastructure as Code (IaC), noti anche come strumenti di automazione intermedia. Questi strumenti aiutano ad automatizzare l'installazione, la gestione e altre attività per il middleware. Ad esempio, uno strumento di automazione può estrarre applicazioni come server di applicazioni, database e strumenti di monitoraggio, con le configurazioni corrette e distribuirle su un server di applicazioni.
Ecco alcuni strumenti di automazione intermedia a codice aperto:
Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache o GPL

Scopri i dettagli su come ottenere una professione richiesta da zero o fare un Level Up in abilità e stipendio, seguendo i corsi online a pagamento di SkillFactory:
- (12 mesi)
altri corsi
- (12 settimane)
- (12 mesi)
- (9 mesi)
- (9 mesi)
Utilità
Fonte: habr.com
