Vad är kontinuerlig integration (CI)?

Kontinuerlig integration är nästa logiska steg efter att ha ett versionskontrollsystem som Git och ett fjärrversionskontrollsystem som GitLab eller GitHub för samarbete. Problemet som stora projekt står inför är detta - När nya dragförfrågningar kommer, måste de testas och sedan integreras i huvudgrenen, och det kan enkelt ta allt från några timmar till några veckor beroende på projektets storlek, platsen för teammedlemmar osv.

Liksom alla sådana problem är det logiska steget att automatisera hela testmomentet. Vi gör det genom att ställa in en utlösare så att när nyare åtaganden slås samman till en filial bygger en agent (till exempel GitLab Runner) automatiskt miljön och koden, kör alla enhetstester och integrationstester mot den. Om det uppstår något fel så ger det en varning och en kraschrapport annars får du en grön signal som säger att allt fungerar.

Naturligtvis kan du också automatisera distributionen, ställa in automatiserad A / B-testning och helt ta bort mänskligt ingripande från processen. Det kallas kontinuerlig leverans och / eller kontinuerlig distribution beroende på automatiseringsnivån. Men vi skulle bara fokusera på kontinuerlig integration i denna handledning.

Förutsättningar

Vi kommer att fokusera på att skapa ett enkelt CI-flöde i handledningen med hjälp av en GitLab-instans över HTTPS som vi täckte i ett tidigare inlägg.

Dessutom antar vi att du har skapat ett användarkonto i denna GitLab-instans och har ett förvar (klonad på din lokala maskin) hanteras under ditt användarnamn. Det är detta arkiv som vi kommer att använda för att visa CI-arbetsflöde. I handledningen kommer dess namn att vara mitt projekt.

För att lista allt:

1. GitLab-instans
2. Tomt arkiv, kallat mitt projekt
3. Lokal klon av detta förvar
4. Din lokala Git-instans konfigurerad för att driva ändringar till avlägsen.

Skapa en enkel app

I det här förvaret, låt oss skapa en enkel nod.js app. Den här appen är en enkel Express.js-server som är avsedd att distribueras i en Docker-behållare. Servern ger en HTTP-nyttolast som säger ”Hello World” i din webbläsare.

Skapa en fil i roten till ditt lokala arkiv app.js och lägg till följande rader:

'använd strikt';
const express = kräver ('express');
// Konstanter
const PORT = 8080;
const HOST = '0.0.0.0 ';
// App
const app = express ();
app.get ('/', (req, res) =>
res.skicka ('Hello world \ n');
);
app.lyssna (PORT, HOST);
trösta.log ('Running on http: // $ HOST: $ PORT');

Skapa sedan en annan fil paket.json och lägg till följande:

"namn": "docker_web_app",
"version": "1.0.0 ",
"description": "Nod.js på Docker ",
"author": "John Doe",
"main": "server.js ",
"skript":
"start": "nodserver.js "
,
"beroenden":
"express": "^ 4.16.1 "

Slutligen skapa en Dockerfil och lägg till följande innehåll i den:

FRÅN nod: 8
# Skapa appkatalog
WORKDIR / usr / src / app
# Installera appberoenden
# Ett jokertecken används för att säkerställa båda paketen.json OCH paketlås.json kopieras
KOPIERA paket *.json ./
KÖR npm-installation
# Om du bygger din kod för produktion
# KÖR npm-installation - endast = produktion
# Knapp för buntapp
KOPIERA…
EXPONERA 8080
CMD ["nod", "app"]

Byggprocessen för den här appen innebär att du skapar en nodbehållare och installerar beroenden (som Express.js-modul). Denna process ska ske utan några fel. För enkelhetens skull kommer vi inte att diskutera några test i denna handledning.

GitLab Runner-rörledning

Nu skulle vi lägga till en annan fil i vårt arkiv som skulle kallas .gitlab-ci.yml . Den här filen innehåller instruktioner för att bygga vårt projekt. Varje gång vi gör ett åtagande om vår GitLab-instans skulle GitLab anropa en löpare för att bygga och testa projektet.

Vi tilldelar denna pipeline olika jobb som kan köra alla köras oberoende av varandra, vilket gör byggprocessen mer flexibel. För ovanstående repo är detta en giltig .gitlab-ci.yml skapa den här filen i roten till ditt arkiv:

bild: nod: senaste
etapper:
- bygga
cache:
vägar:
- nodmoduler /
installationsberoende:
scen: bygg
manus:
- npm installera

Vi har bara ett steg bygga och det har bara npm installera som ett manus. Detta är ett kommando som du måste köra manuellt varje gång en ändring kommer till ditt projekt. GitLab-löparen skulle göra detta åt dig. Runner kan installeras i ett Kubernetes-kluster, en VPS i molnet eller i din lokala arbetsstation och om den är aktiv väntar den på instruktioner från GitLab-servern för att utföra en byggnad.

Vi skulle installera och konfigurera en Runner lokalt för att automatisera den.

Få Runner Token

Öppna ditt förråd på GitLab och besök dess CD / CI-inställningar. Det är Inställningar → CD / CI inuti testförvaret.

Lämna inställningen Auto DevOps till standard och klicka på BYGGA UT för att utöka inställningarna för Allmänna rörledningar så visas ett Runner-token. Kopiera dess värde och håll det naturligtvis privat om du värdesätter ditt projekt.

Med den här token kan din lokala GitLab Runner-körbar registreras säkert med din GitLab-instans.

Installerar GitLab Runner

GitLab-Runner är ett litet lättviktigt program skrivet i Go som kör CI-relaterat jobb på din lokala maskin och skickar resultaten till GitLab för att den ska överväga ändringarna. Det är en enda körbar binär som kan installeras på alla större operativsystem. Följ instruktionerna här för ditt specifika operativsystem. Dessa installationer varierar väldigt mycket, så det är omöjligt att lista dem alla.

Alternativt kan du använda Runner som en Docker-tjänst, men låt oss bara hålla oss till traditionell installation, för kommandona är enklare att läsa och förstå för läsaren. När du har installerat den på din lokala arbetsstation måste du utföra kommandot:

$ gitlab-runner register

Detta kommer att ställa dig flera frågor som börjar med din GitLab-CI-koordinator som skulle vara din GitLab-instans:

$ gitlab-runner register
Ange webbadressen för gitlab-ci-koordinator (e.g. https: // gitlab.com /):
https: // gitlab.exempel.com

Det skulle då be om din Runner-token, som vi fick i föregående avsnitt:

Ange gitlab-ci-token för den här löparen:

Your_Secret_Token

Sedan för en identifierande beskrivning kan du bara hoppa över att lägga till några taggar genom att trycka på :

Ange gitlab-ci-beskrivningen för den här löparen:

[Värdnamn]: Demo för att ställa in CI med Runner

Ange gitlab-ci-taggarna för den här löparen (kommaseparerad):

Registrering av löpare ... lyckades

Viktigast, det kommer att be dig om en exekutör (mer om detta på ett ögonblick), vi väljer Docker för vårt exempel.

Ange exekutören: docker-ssh + maskin, kubernetes, paralleller, skal, ssh, virtualbox, docker + maskin, docker, docker-ssh:

hamnarbetare

Base-dockerbilden inom vilken byggningen skulle äga rum måste sedan specificeras, vår exempelapp använder nod så att vi kommer att specificera en nodbild:

Ange standard Docker-bilden (t.ex.g. rubin: 2.1):

nod: senaste

Löpare registrerade framgångsrikt. Starta gärna, men om den redan är igång bör konfigurationen laddas om automatiskt!

Nu är något som behöver lite förklaring här vad exakt är exekutörer? Sättet CI-arbete flödar på är att byggandet av moduler, deras testning osv är kända som jobb och exekutörer utför dessa jobb. Om du valde VirtualBox som en exekutor skulle GitLab-löpare integreras med den lokalt installerade VirtualBox och köra CI-jobb i en virtuell dator. Om du väljer kubernetes skulle det hända i ditt Kubernetes-kluster, i molnet, om du väljer ssh kan du delegera CI-uppgifterna till en fjärrserver.

Vårt exempelprojekt är baserat på Docker, så det är vettigt att använda Docker som vår exekutör. Du behöver ha Docker installeras lokalt för detta.

Att ha flera alternativ för exekutörer gör Runner mer flexibel. Du kanske vill bygga lokalt eftersom projektfilerna är för stora eller kanske du vill köra på en fjärrserver med 20 kärnor och en halv terabyte RAM eftersom byggprocessen är beräkningsintensiv. Att specificera ett exekveringsalternativ ger dig den flexibiliteten.

Slutligen, i ditt skal vill du starta Runner-tjänsten:

$ gitlab-runner start

Seende .gitlab-ci.yml i aktion

Nu har vi gjort alla dessa ändringar i vårt lokala repo skapat hela appen.js, paket.json, Dockerfile och .gitlab-ci.yml-filer. Förmodligen har du begått ändringarna i ditt lokala arkiv genom att köra:

$ git stage file_name
$ git commit -m “Commit Message”

Låt oss driva ändringarna till vår fjärranslutna GitLab.

$ git push -u ursprung

Du kan sedan öppna ditt projekt i GitLab, gå till mitt-projekt → Rörledning och du kommer att se detta en tagg som säger "passerat" bredvid det åtagande du gjort. Efterföljande åtaganden kommer också att ha taggar.

Så det är grunderna i CI med GitLab och Runner. Hoppas att du gillade inlägget och lärde dig något nytt av det.