Se sei nuovo a DevOps, dai un'occhiata a questa guida in cinque passaggi per creare la tua prima pipeline.
DevOps è diventata la soluzione standard per correggere processi di sviluppo software lenti, sconnessi o interrotti. Il problema è che se sei nuovo a DevOps e non sai da dove iniziare, potresti non comprendere queste tecniche. Questo articolo discuterà la definizione di una pipeline DevOps e fornirà anche istruzioni in cinque passaggi per crearne una. Sebbene questo tutorial non sia esaustivo, dovrebbe fornirti le basi per iniziare il tuo viaggio ed espandere le tue conoscenze in futuro. Ma cominciamo con la storia.
Il mio viaggio DevOps
In precedenza ho lavorato nel team cloud di Citi Group, sviluppando un'applicazione web Infrastructure-as-a-Service (IaaS) per gestire l'infrastruttura cloud di Citi, ma ero sempre interessato a come rendere il processo di sviluppo più efficiente e apportare un cambiamento culturale positivo a il team di sviluppo. Ho trovato la risposta in un libro consigliato da Greg Lavender, CTO di Cloud Architecture and Infrastructure presso Citi. Il libro si chiamava The Phoenix Project () e spiega i principi di DevOps, ma si legge come un romanzo.
La tabella in fondo al libro mostra la frequenza con cui aziende diverse distribuiscono i propri sistemi in un ambiente di rilascio:
Amazon: 23 al giorno
Google: 5 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? Questo perché queste aziende hanno capito come creare una pipeline DevOps quasi perfetta.
Eravamo lontani da questo finché non abbiamo implementato DevOps in Citi. Allora il mio team aveva ambienti diversi, ma la distribuzione 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 la distribuzione contemporaneamente, quindi gli sviluppatori dovevano comunicarsi reciprocamente le loro intenzioni, il che era piuttosto una seccatura. Inoltre, si verificavano problemi con la copertura del codice di test di basso livello, processi di distribuzione manuale complessi e l'impossibilità di monitorare la distribuzione del codice associato a un'attività o una user story specifica.
Ho capito che bisognava fare qualcosa e ho trovato un collega che la pensava allo stesso modo. Abbiamo deciso di collaborare alla creazione della pipeline DevOps iniziale: lui ha configurato una macchina virtuale Tomcat e un server applicativo mentre io lavoravo su Jenkins, ha integrato Atlassian Jira e BitBucket e ho lavorato sulla copertura del codice di prova. Questo progetto parallelo ha avuto molto successo: abbiamo automatizzato quasi completamente molti processi, raggiunto un tempo di attività quasi del 100% sul nostro server di sviluppo, fornito monitoraggio e migliore copertura dei test del codice e aggiunto la possibilità di collegare i rami Git ai problemi o alle distribuzioni di Jira. La maggior parte degli strumenti che abbiamo utilizzato per creare la nostra pipeline DevOps erano open source.
Ora capisco quanto fosse semplice la nostra pipeline DevOps: non abbiamo utilizzato estensioni come i file Jenkins o Ansible. Tuttavia, questa semplice pipeline ha funzionato 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 più persone “Cos’è DevOps?”, probabilmente otterrai risposte diverse. DevOps, come Agile, si è evoluto per abbracciare molte discipline diverse, ma la maggior parte delle persone sarà d'accordo su alcune cose: DevOps è una pratica di sviluppo software o ciclo di vita dello sviluppo software (SDLC) il cui principio centrale sta cambiando la cultura in cui sviluppatori e non- gli sviluppatori esistono in un ambiente in cui:
Le operazioni che prima venivano eseguite manualmente sono state automatizzate;
Ognuno fa quello che sa fare meglio;
Il numero di implementazioni in un certo periodo di tempo aumenta; Aumenti della produttività;
Maggiore flessibilità di sviluppo.
Sebbene disporre degli 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 la distribuzione continua (CI/CD). In questa pipeline, gli ambienti hanno fasi diverse (ad esempio DEV, INT, TST, QA, UAT, STG, PROD), molte operazioni sono automatizzate e gli sviluppatori possono scrivere codice di alta qualità, ottenere agilità di sviluppo e tassi di distribuzione elevati.
Questo articolo descrive un approccio in cinque passaggi per creare una pipeline DevOps come quella mostrata nel diagramma seguente utilizzando strumenti open source.
Passaggio 1: metodi CI/CD
La prima cosa di cui hai bisogno è uno strumento CI/CD. Jenkins, uno strumento open source basato su Java e concesso in licenza con la licenza MIT, è lo strumento che ha reso popolare DevOps ed è diventato lo standard de facto.
Allora cos'è Jenkins? Consideralo come una sorta di magico telecomando universale in grado di comunicare e organizzare vari servizi e strumenti. Di per sé, uno strumento CI/CD come Jenkins è inutile, ma diventa più potente quando si connette a diversi strumenti e servizi.
Jenkins è solo uno dei tanti strumenti CI/CD open source che puoi utilizzare per creare la tua 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 non c'è molto che puoi fare al momento. Passiamo alla fase successiva del viaggio DevOps.
Passaggio 2: gestire i sistemi di controllo del codice sorgente
Il modo migliore (e forse più semplice) per verificare che il tuo strumento CI/CD possa fare la sua magia è integrarlo con uno strumento di controllo del codice sorgente (SCM). Perché hai bisogno del controllo del codice sorgente? Diciamo che stai sviluppando un'applicazione. Ogni volta che crei un'applicazione, stai programmando e non importa se usi Java, Python, C++, Go, Ruby, JavaScript o uno qualsiasi degli innumerevoli linguaggi di programmazione. Il codice che scrivi si chiama codice sorgente. All'inizio, soprattutto quando lavori da solo, probabilmente va bene mettere tutto in una directory locale. Ma man mano che il progetto diventa più grande e inviti altre persone a collaborare, hai bisogno di un modo per prevenire i conflitti condividendo al tempo stesso in modo efficace le modifiche. È inoltre necessario un modo per ripristinare le versioni precedenti, poiché la creazione di backup e il copia/incolla al loro interno stanno diventando obsoleti. Tu (e i tuoi compagni di squadra) avete bisogno di qualcosa di meglio.
È qui che il controllo del codice sorgente diventa quasi una necessità. Questo strumento memorizza il tuo codice in 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, ed è giusto che sia così. Consiglio vivamente di utilizzare Git, anche se ci sono altre opzioni open source se preferisci.
Git: GPLv2 e LGPL v2.1
Sovversione: Apache 2.0
Sistema di versioni concorrenti (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+
Ecco come appare una pipeline DevOps con l'aggiunta dei controlli del codice sorgente.
Uno strumento CI/CD può automatizzare i processi di revisione, acquisizione del codice sorgente e collaborazione tra i membri. Non male? Ma come trasformarlo in un'applicazione funzionante affinché miliardi di persone possano usarlo e apprezzarlo?
Passaggio 3: crea uno strumento di automazione della build
Grande! Puoi rivedere il codice e apportare modifiche al controllo del codice sorgente e invitare i tuoi amici a collaborare allo sviluppo. Ma non hai ancora creato un'applicazione. Per creare un'applicazione Web, è necessario compilarla e impacchettarla in un formato batch distribuibile o eseguirla come file eseguibile. (Si noti che un linguaggio di programmazione interpretato come JavaScript o PHP non necessita di essere compilato).
Utilizza uno strumento di automazione della compilazione. Indipendentemente dallo strumento di automazione della compilazione che decidi di utilizzare, hanno tutti lo stesso obiettivo: creare il codice sorgente nel formato desiderato e automatizzare l'attività di pulizia, compilazione, test e distribuzione in un ambiente specifico. Gli strumenti di creazione variano a seconda del linguaggio di programmazione, ma ecco alcune opzioni open source comuni.
Nome
Licenza
Linguaggio di programmazione
Maven
Apache 2.0
Java
Formica
Apache 2.0
Java
Gradle
Apache 2.0
Java
Bazel
Apache 2.0
Java
Make
GNU
N/A
Grugnito
CON
JavaScript
Sorso
CON
JavaScript
costruttore
Apache
Ruby
Rastrello
CON
Ruby
AAP
GNU
Python
SCons
CON
Python
BitBake
GPLv2
Python
torta
CON
C#
ASDF
Espatriato (MIT)
LISP
completo
BSD
Haskell
Grande! Puoi inserire i file di configurazione dello strumento di automazione della build nel tuo sistema di controllo del codice sorgente e lasciare che il tuo strumento CI/CD metta tutto insieme.
Va tutto bene, vero? Ma dove distribuire la tua applicazione?
Passaggio 4: server delle applicazioni Web
Per ora, hai un file compresso che può essere eseguibile o installabile. Affinché qualsiasi applicazione sia veramente utile, deve fornire qualche tipo di servizio o interfaccia, ma è necessario un contenitore per ospitare l'applicazione.
Un server di applicazioni Web è proprio un contenitore di questo tipo. Il server fornisce un ambiente in cui è possibile definire la logica del pacchetto da distribuire. Il server fornisce anche un'interfaccia e offre servizi web esponendo i socket al mondo esterno. Hai bisogno di un server HTTP e di un ambiente (come una macchina virtuale) per installarlo. Per ora, supponiamo che imparerai di più a riguardo (anche se tratterò i contenitori di seguito).
Esistono diversi server di applicazioni Web open source.
Nome
Licenza
Linguaggio di programmazione
Micio
Apache 2.0
Java
Molo
Apache 2.0
Java
Volo selvaggio
Pubblico minore GNU
Java
GlassFish
CDDL e GNU meno pubblici
Java
Django
BSD a 3 clausole
Python
Tornado
Apache 2.0
Python
gunicorn
CON
Python
Python
CON
Python
Rails
CON
Ruby
Node.js
CON
Javascript
La tua pipeline DevOps è quasi pronta per l'uso. Buon lavoro!
Sebbene tu possa fermarti qui e gestire tu stesso l'integrazione, la qualità del codice è una cosa importante di cui uno sviluppatore di app deve preoccuparsi.
Passaggio 5: copertura del test del codice
L'implementazione dei test può essere un altro requisito complicato, ma gli sviluppatori devono individuare tempestivamente eventuali bug nell'applicazione e migliorare la qualità del codice per garantire la soddisfazione degli utenti finali. Fortunatamente, esistono molti strumenti open source per testare il codice e fornire consigli per migliorarne la qualità. La cosa ancora migliore è che la maggior parte degli strumenti CI/CD può connettersi a questi strumenti e automatizzare il processo.
Il test del codice è composto da due parti: framework di test del codice che ti aiutano a scrivere ed eseguire test e strumenti di suggerimento che ti aiutano a migliorare la qualità del tuo codice.
Sistemi di test del codice
Nome
Licenza
Linguaggio di programmazione
JUnit
Licenza pubblica Eclipse
Java
EasyMock
Apache
Java
mockito
CON
Java
PowerMock
Apache 2.0
Java
Pytest
CON
Python
Ipotesi
Mozilla
Python
Tox
CON
Python
Sistemi di raccomandazione per il miglioramento del codice
Nome
Licenza
Linguaggio di programmazione
Copertura
GNU
Java
CodiceCopertina
Eclissi pubblica (EPL)
Java
Copertura.py
Apache 2.0
Python
Emma
Licenza pubblica comune
Java
JaCoCo
Licenza pubblica Eclipse
Java
Ipotesi
Mozilla
Python
Tox
CON
Python
Jasmine
CON
JavaScript
Karma
CON
JavaScript
Moca
CON
JavaScript
Scherzare
CON
JavaScript
Tieni presente che la maggior parte degli strumenti e dei framework sopra menzionati sono scritti per Java, Python e JavaScript, poiché C++ e C# sono linguaggi di programmazione proprietari (sebbene GCC sia open source).
Ora che hai implementato gli strumenti di copertura del test, la tua pipeline DevOps dovrebbe essere simile al diagramma mostrato all'inizio di questo tutorial.
Passaggi aggiuntivi
contenitori
Come ho 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? La spiegazione breve è che una macchina virtuale necessita di un'enorme quantità di memoria del sistema operativo, superiore alla dimensione dell'applicazione, mentre un contenitore necessita solo di poche librerie e configurazioni per eseguire l'applicazione. Ovviamente, ci sono ancora usi importanti per una macchina virtuale, ma un contenitore è una soluzione leggera per ospitare un'applicazione, incluso un server delle applicazioni.
Sebbene esistano altre opzioni di contenitori, le più popolari sono Docker e Kubernetes.
Finestra mobile: Apache 2.0
Kubernetes: Apache 2.0
Strumenti di automazione intermedi
La nostra pipeline DevOps si concentra principalmente sulla creazione e distribuzione di applicazioni collaborative, ma ci sono molte altre cose che possono essere fatte con gli strumenti DevOps. Uno di questi è l’uso degli strumenti Infrastructure as Code (IaC), noti anche come strumenti di automazione del middleware. Questi strumenti aiutano ad automatizzare l'installazione, la gestione e altre attività per il middleware. Quindi, ad esempio, uno strumento di automazione può estrarre applicazioni come un server di applicazioni Web, un database e uno strumento di monitoraggio con le configurazioni corrette e distribuirle sul server delle applicazioni.
Ecco alcuni strumenti di automazione del middleware open source:
Ansible: pubblico GNU
SaltStack: Apache 2.0
Cuoco: Apache 2.0
Marionetta: Apache o GPL
Scopri i dettagli su come ottenere da zero una professione ambita o salire di livello in termini di competenze e stipendio frequentando corsi online a pagamento da SkillFactory:
- (12 mesi)
più corsi
- (12 settimane)
- (12 mesi)
- (9 mesi)
- (9 mesi)
utile
Fonte: habr.com