Cos'è l'integrazione continua (CI)?

L'integrazione continua è il prossimo passo logico dopo avere un sistema di controllo della versione come Git e un sistema di controllo della versione remoto come Gitlab o GitHub per sforzi collaborativi. Il problema che i grandi progetti devono affrontare è questo: come arrivano nuove richieste di pull, devono essere testati e quindi integrati nel ramo principale e questo sforzo può richiedere facilmente da poche ore a poche settimane a seconda delle dimensioni del progetto, la posizione dei membri del team, ecc.

Come qualsiasi problema del genere, il passaggio logico è automatizzare l'intero rigmarole dei test. Lo facciamo impostando un trigger in modo tale che ogni volta che i nuovi commit vengono uniti in una filiale un agente (Gitlab Runner, ad esempio) crea automaticamente l'ambiente e il codice, esegue tutti i test unitari e i test di integrazione contro di esso. Se si verifica qualche errore, allora dà un avvertimento e un rapporto sul crash altrimenti si ottiene un segnale verde che dice tutto funziona.

Naturalmente, portato al suo estremo logico, puoi anche automatizzare la distribuzione, impostare test A/B automatizzato e rimuovere l'intervento umano dal processo. Che è definito come consegna continua e/o implementazione continua a seconda del livello di automazione. Ma ci concentreremo solo sull'integrazione continua in questo tutorial.

Prerequisiti

Ci concentreremo sulla creazione di un semplice flusso CI nel tutorial usando un'istanza Gitlab su HTTPS che abbiamo trattato in un post precedente.

Inoltre, supponiamo anche che tu abbia impostato un account utente in questa istanza Gitlab e hai un repository (clonato sulla macchina locale) gestito sotto il tuo nome utente. È questo repository che utilizzeremo per dimostrare il flusso di lavoro CI. Nel tutorial, il suo nome sarà il mio progetto.

Per elencare tutto:

1. Gitlab istanza
2. Repository vuoto, chiamato my-project
3. Clone locale di questo repository
4. L'istanza GIT locale configurata per spingere le modifiche in a distanza.

Creazione di un'app semplice

In questo repository, creiamo un nodo semplice.app js. Questa app è un semplice espresso.server JS che dovrebbe essere distribuito in un contenitore Docker. Il server fornisce un payload HTTP che dice "Hello World" nel tuo browser.

Nella radice del repository locale, crea un file app.js e aggiungere le seguenti righe:

"Usa rigoroso";
const espress = requisito ('express');
// Costanti
port const = 8080;
const host = '0.0.0.0 ';
// app
const app = express ();
app.get ('/', (req, res) =>
res.inviare ('Hello World \ n');
);
app.Ascolta (porta, host);
console.log ('in esecuzione su http: // $ host: $ port');

Quindi crea un altro file pacchetto.JSON e aggiungi quanto segue:

"Nome": "Docker_Web_App",
"Versione": "1.0.0 ",
"Descrizione": "Node.JS su Docker ",
"Autore": "John Doe",
"Main": "Server.js ",
"Script":
"Start": "Node Server.js "
,
"Dipendenze":
"Express": "^4.16.1 "

Infine, crea un file Dockerfile e aggiungi i seguenti contenuti:

Dal nodo: 8
# Crea la directory app
Workdir/usr/src/app
# Installa le dipendenze dell'app
# Un jolly viene utilizzato per garantire entrambi i pacchetti.JSON e PACKE-LOCK.JSON sono copiati
Copia pacchetto*.JSON ./
Esegui l'installazione NPM
# Se stai costruendo il tuo codice per la produzione
# Esegui NPM Install --Only = Production
# Fonte dell'app bundle
COPIA…
Esporre 8080
Cmd ["nodo", "app"]

Il processo di build per questa app implicherebbe la creazione di un contenitore di nodi e l'installazione delle dipendenze (come Express.Modulo JS). Questo processo dovrebbe avvenire senza errori. Per motivi di semplicità, non discuteremo di alcun test in questo tutorial.

Gitlab Runner Pipeline

Ora aggiungeremmo un altro file al nostro repository che verrebbe chiamato .gitlab-ci.YML . Questo file conterrebbe le istruzioni per creare il nostro progetto. Ora, ogni volta che spingiamo un commit nella nostra istanza Gitlab, Gitlab avrebbe invocato un corridore per costruire e testare il progetto.

Assegniamo questa pipeline varie lavori che può essere eseguito tutto in modo indipendente l'uno dall'altro, rendendo il processo di build più flessibile. Per il repo di cui sopra, questo è valido .gitlab-ci.YML Crea questo file nella radice del repository:

Immagine: nodo: ultimo
Fase:
- costruire
Cache:
Paths:
- node_modules/
install_dipendencys:
Fase: build
Script:
- Installazione NPM

Abbiamo solo una fase costruire E ha solo Installazione NPM come sceneggiatura. Questo è un comando che dovresti eseguire manualmente ogni volta che arriva un cambiamento al tuo progetto. Il corridore di Gitlab lo farebbe per te. Il corridore potrebbe essere installato in un cluster Kubernetes, un VPS nel cloud o nella workstation locale e se è attivo, sarà in attesa di istruzioni dal server Gitlab per eseguire una build.

Installiamo e configuriamo a livello locale per automatizzarlo.

Ottenere il token del corridore

Apri il tuo repository su Gitlab e visita le sue impostazioni CD/CI. Quello è Impostazioni → CD/CI All'interno del tuo repository di test.

Lascia l'impostazione Auto DevOps al suo valore predefinito e fai clic su ESPANDERE Per espandere le impostazioni generali della pipeline e ti verrà visualizzato un token runner. Copia il suo valore e, ovviamente, mantienilo privato se apprezzi il tuo progetto.

Usando questo token, il tuo eseguibile Gitlab Runner locale sarà in grado di registrarsi in modo sicuro con l'istanza Gitlab.

Installazione di Gitlab Runner

Gitlab-runner è un piccolo programma leggero scritto in GO che gestisce CI correlato lavori sulla macchina locale e invia i risultati a Gitlab per considerare le modifiche. È un singolo binario eseguibile che può essere installato su qualsiasi sistema operativo importante. Segui le istruzioni qui, per il tuo particolare sistema operativo. Queste installazioni variano selvaggiamente, quindi elencarle tutte è impossibile.

In alternativa puoi usare il runner come servizio Docker, ma bastiamo semplicemente l'installazione tradizionale, poiché i comandi sono più semplici da leggere e capire per il lettore. Una volta installato sulla workstation locale, è necessario eseguire il comando:

$ Gitlab-Runner Register

Questo ti farà diverse domande a partire dal tuo coordinatore Gitlab-CI che sarebbe la tua istanza Gitlab:

$ Gitlab-Runner Register
Inserisci l'URL del coordinatore Gitlab-CI (E.G. https: // gitlab.com/):
https: // gitlab.esempio.com

Chiederebbe quindi il tuo token del corridore, che abbiamo ottenuto nella sezione precedente:

Inserisci il token Gitlab-CI per questo corridore:

Your_secret_token

Quindi per una descrizione identificativa e puoi semplicemente saltare aggiungendo eventuali tag premendo:

Inserisci la descrizione Gitlab-CI per questo corridore:

[Nome host]: demo per l'impostazione di CI usando il runner

Inserisci i tag Gitlab-CI per questo corridore (virgola separata):

Registrazione del corridore ... è riuscito

Ancora più importante, ti chiederà un esecutore (ne parleremo tra un momento), sceglieremo Docker per il bene del nostro esempio.

Inserisci l'esecutore: Docker-Ssh+Machine, Kubernetes, Parallels, Shell, SSH, VirtualBox, Docker+Machine, Docker, Docker-SSH:

Docker

L'immagine Docker di base all'interno della quale si verificherebbe quindi la build deve essere specificata, la nostra app di esempio utilizza il nodo in modo da specificare un'immagine del nodo:

Immettere l'immagine Docker predefinita (E.G. Ruby: 2.1):

Nodo: ultimo

Runner registrato con successo. Sentiti libero di avviarlo, ma se è già in esecuzione la configurazione dovrebbe essere ricaricata automaticamente!

Ora qualcosa che ha bisogno di una piccola spiegazione qui è esattamente cosa esecutori? Il modo in cui il lavoro di CI scorre è che la costruzione di moduli, i loro test, ecc lavori e gli esecutori eseguono quei lavori. Se hai scelto VirtualBox come esecutore, Gitlab Runner si integrerebbe con VirtualBox installato localmente ed eseguirà i lavori CI in una VM, se selezioni Kubernetes, succederebbe nel tuo cluster Kubernetes, nel cloud, se si seleziona SSH delegare le attività CI a un server remoto.

Il nostro progetto di esempio si basa su Docker, quindi ha senso usare Docker come nostro esecutore. Devi avere Docker installato localmente per questo.

Avere più opzioni per gli esecutori rende il corridore più flessibile. Potresti voler costruire localmente perché i file di progetto sono troppo grandi o potresti voler eseguire in un server remoto con 20 core e mezzo terabyte di RAM poiché il processo di build è computazionalmente intensivo, specificando un'opzione esecutiva ti dà tale flessibilità.

Infine, nella tua shell vorresti avviare il servizio Runner:

$ gitlab-runner inizio

Vedendo .gitlab-ci.YML in azione

Ora abbiamo apportato tutte queste modifiche nel nostro repository locale creato tutta l'app.JS, pacchetto.JSON, Dockerfile e .gitlab-ci.file YML. Presumibilmente, hai commesso le modifiche al tuo repository locale eseguendo:

$ git stage file_name
$ git commit -m "commit messaggio"

Spingiamo le modifiche al nostro Gitlab remoto.

$ git push -u origine

Puoi quindi aprire il tuo progetto in Gitlab, andare a My-Project → Pipeline E vedrai questo un tag che dice "passato" accanto al commit che hai fatto. Commit successivi, avrà anche tag.

Quindi sono le basi di CI che usano Gitlab e Runner. Spero ti sia piaciuto il post e abbia imparato qualcosa di nuovo da esso.