Hvad er kontinuerlig integration (CI)?

Kontinuerlig integration er det næste logiske trin efter at have et versionskontrolsystem som Git og et fjernbetjeningskontrolsystem som GitLab eller GitHub til samarbejde. Problemet, som store projekter står over for, er dette - Da nye pull-anmodninger kommer, skal de testes og derefter integreres i mastergrenen, og denne indsats kan let tage alt fra et par timer til et par uger afhængigt af projektets størrelse, placeringen af ​​teammedlemmer osv.

Som ethvert sådant problem er det logiske trin at automatisere hele testmargen. Vi gør det ved at oprette en trigger, så hver gang nyere forpligtelser flettes i en gren, bygger en agent (f.eks. GitLab Runner) automatisk miljøet og koden, kører alle enhedstestene og integrationstestene mod det. Hvis der er opstået nogen fejl, giver det en advarsel og en nedbrudsrapport, ellers får du et grønt signal om, at alt fungerer.

Selvfølgelig, taget til sin logiske ekstremitet, kan du også automatisere implementeringen, opsætte automatiseret A / B-test og helt fjerne menneskelig indblanding fra processen. Det betegnes som kontinuerlig levering og / eller kontinuerlig implementering afhængigt af automatiseringsniveauet. Men vi vil bare fokusere på kontinuerlig integration i denne vejledning.

Forudsætninger

Vi vil fokusere på at oprette et simpelt CI-flow i vejledningen ved hjælp af en GitLab-forekomst over HTTPS, som vi dækkede i et tidligere indlæg.

Derudover antager vi også, at du har oprettet en brugerkonto i denne GitLab-forekomst og har et lager (klonet på din lokale maskine) administreret under dit brugernavn. Det er dette lager, vi vil bruge til at demonstrere CI-arbejdsgang. I vejledningen bliver navnet det mit-projekt.

For at liste det hele:

1. GitLab-forekomst
2. Tomt lager, kaldet mit-projekt
3. Lokal klon af dette arkiv
4. Din lokale Git-instans er konfigureret til at skubbe ændringer til fjern.

Oprettelse af en simpel app

I dette lager skal vi oprette en simpel node.js app. Denne app er en simpel Express.js-server, som er beregnet til at blive implementeret i en Docker-container. Serveren giver en HTTP-nyttelast, der siger "Hello World" i din browser.

Opret en fil i roden til dit lokale arkiv app.js og tilføj følgende linjer:

'brug streng';
const express = kræve ('express');
// Konstanter
const PORT = 8080;
const HOST = '0.0.0.0 ';
// App
const app = express ();
app.get ('/', (req, res) =>
res.send ('Hej verden \ n');
);
app.lyt (PORT, HOST);
konsol.log ('Kører på http: // $ HOST: $ PORT');

Opret derefter en anden fil pakke.json og tilføj følgende til det:

"navn": "docker_web_app",
"version": "1.0.0 ",
"beskrivelse": "Knude.js på Docker ",
"author": "John Doe",
"main": "server.js ",
"scripts":
"start": "node-server.js "
,
"afhængigheder":
"express": "^ 4.16.1 "

Til sidst skal du oprette en Dockerfil og tilføj følgende indhold til det:

FRA knude: 8
# Opret app-bibliotek
WORKDIR / usr / src / app
# Installer appafhængigheder
# Et jokertegn bruges til at sikre begge pakker.json OG pakke-lås.json kopieres
COPY-pakke *.json ./
KØR npm installation
# Hvis du bygger din kode til produktion
# KØR npm installation - kun = produktion
# Bundle-appkilde
KOPI…
EKSPONER 8080
CMD ["node", "app"]

Bygningsprocessen til denne app involverer oprettelse af en nodebeholder og installation af afhængigheder (som Express.js-modul). Denne proces skal ske uden nogen fejl. For enkelheds skyld vil vi ikke diskutere nogen test i denne vejledning.

GitLab Runner-rørledning

Nu vil vi tilføje en anden fil til vores lager, der kaldes .gitlab-ci.yml . Denne fil indeholder instruktionerne til at opbygge vores projekt. Hver gang vi lægger en forpligtelse til vores GitLab-forekomst, vil GitLab påkalde en Runner til at opbygge og teste projektet.

Vi tildeler denne pipeline forskellige job som kan køre alle køre uafhængigt af hinanden, hvilket gør byggeprocessen mere fleksibel. For ovenstående repo er dette gyldigt .gitlab-ci.yml Opret denne fil i roden af ​​dit arkiv:

billede: node: seneste
niveauer:
- bygge
cache:
stier:
- node_modules /
installationsafhængigheder:
fase: bygge
manuskript:
- npm installation

Vi har kun et trin bygge og det har bare npm installation som et script. Dette er en kommando, du skal køre manuelt hver gang en ændring kommer til dit projekt. GitLab-løberen ville gøre dette for dig. Runner kan installeres i en Kubernetes-klynge, en VPS i skyen eller i din lokale arbejdsstation, og hvis den er aktiv, venter den på instruktioner fra GitLab-serveren til at udføre en build.

Vi installerer og konfigurerer en Runner lokalt til at automatisere den.

Få Runner Token

Åbn dit lager på GitLab, og besøg dets CD / CI-indstillinger. Det er Indstillinger → CD / CI inde i dit test arkiv.

Lad indstillingen Auto DevOps være standard, og klik på UDVIDE for at udvide de generelle rørledningsindstillinger, og du får vist et Runner-token. Kopier dens værdi, og hold den selvfølgelig privat, hvis du sætter pris på dit projekt.

Ved hjælp af dette token vil din lokale GitLab Runner-eksekverbar være i stand til at registrere sikkert med din GitLab-forekomst.

Installation af GitLab Runner

GitLab-Runner er et lille letvægtsprogram skrevet i Go, der kører CI-relateret job på din lokale maskine og sender resultaterne til GitLab for at den kan overveje ændringerne. Det er en enkelt eksekverbar binær, der kan installeres på ethvert større operativsystem. Følg instruktionerne her for dit bestemte operativsystem. Disse installationer varierer voldsomt, så det er umuligt at liste dem alle.

Alternativt kan du bruge Runner som en Docker-tjeneste, men lad os bare holde os til traditionel installation, for kommandoerne er lettere at læse og forstå for læseren. Når du har installeret det på din lokale arbejdsstation, skal du udføre kommandoen:

$ gitlab-runner register

Dette vil stille dig flere spørgsmål, der begynder med din GitLab-CI-koordinator, som ville være din GitLab-forekomst:

$ gitlab-runner register
Indtast venligst gitlab-ci koordinator URL (e.g. https: // gitlab.com /):
https: // gitlab.eksempel.com

Det vil derefter bede om dit Runner-token, som vi opnåede i det foregående afsnit:

Indtast gitlab-ci-token for denne løber:

Dit_Hemmelige_Token

Så for en identificerende beskrivelse, og du kan bare springe over at tilføje eventuelle tags ved at trykke :

Indtast gitlab-ci beskrivelsen for denne løber:

[Hostname]: Demo til opsætning af CI ved hjælp af Runner

Indtast gitlab-ci-tags for denne løber (kommasepareret):

Registrering af løber ... lykkedes

Vigtigst er det, det vil bede dig om en eksekutor (mere om dette om et øjeblik), vi vælger Docker af hensyn til vores eksempel.

Indtast venligst eksekutoren: docker-ssh + maskine, kubernetes, paralleller, shell, ssh, virtualbox, docker + maskine, docker, docker-ssh:

docker

Base docker-billedet, inden for hvilket bygningen ville finde sted, skal derefter specificeres, vores eksempelapp bruger node, så vi specificerer et nodebillede:

Indtast standard Docker-billedet (f.eks.g. rubin: 2.1):

node: seneste

Løber blev registreret med succes. Du er velkommen til at starte det, men hvis det allerede kører, skal konfigurationen genindlæses automatisk!

Nu er der noget, der har brug for en lille forklaring her, hvad der præcist er eksekutører? Måden CI-arbejde flyder på er, at opbygningen af ​​moduler, deres test osv. Alle er kendt som job og eksekutører udfører disse job. Hvis du valgte VirtualBox som eksekutor, ville GitLab-runner integrere med den lokalt installerede VirtualBox og køre CI-job i en VM, hvis du vælger kubernetes, ville det ske i din Kubernetes-klynge i skyen, hvis du vælger ssh, kan du delegere CI-opgaver til en ekstern server.

Vores eksempelprojekt er baseret på Docker, så det giver mening at bruge Docker som vores eksekutor. Du skal have Docker installeret lokalt for det.

At have flere muligheder for eksekutører gør Runner mere fleksibel. Det kan være en god idé at opbygge lokalt, fordi projektfilerne er for store, eller du vil muligvis udføre på en ekstern server med 20 kerner og en halv terabyte RAM, fordi byggeprocessen er beregningsintensiv, ved at angive en eksekveringsmulighed giver dig den fleksibilitet.

Endelig vil du i din skal starte Runner-tjenesten:

$ gitlab-runner start

Ser .gitlab-ci.yml i aktion

Nu har vi foretaget alle disse ændringer i vores lokale repo oprettet hele appen.js, pakke.json, Dockerfile og .gitlab-ci.yml-filer. Formodentlig har du foretaget ændringerne i dit lokale arkiv ved at køre:

$ git fase filnavn
$ git commit -m “Commit Message”

Lad os skubbe ændringerne til vores eksterne GitLab.

$ git push-u oprindelse

Du kan derefter åbne dit projekt i GitLab, gå til mit-projekt → Rørledning og du vil se dette et mærke, der siger "bestået" ved siden af ​​den forpligtelse, du har foretaget. Efterfølgende forpligtelser vil også have tags.

Så det er det grundlæggende ved CI ved hjælp af GitLab og Runner. Håber du nød indlægget og lærte noget nyt af det.