Hva er kontinuerlig integrasjon (CI)?

Kontinuerlig integrasjon er det neste logiske trinnet etter å ha et versjonskontrollsystem som Git og et fjernversjonskontrollsystem som Gitlab eller GitHub for samarbeidsinnsatser. Problemet som store prosjekter står overfor er dette - når nye trekkforespørsler kommer, må de testes og deretter integreres i mastergrenen, og denne innsatsen kan lett ta alt fra noen timer til noen uker, avhengig av størrelsen på prosjektet, Plasseringen av teammedlemmer osv.

Som et slikt problem, er det logiske trinnet å automatisere hele testing av Rigmarole. Vi gjør det ved å sette opp en trigger slik at hver gang nyere forpliktelser blir slått sammen til en gren en agent (for eksempel Gitlab -løper. Hvis det er noen feil oppstått, gir det en advarsel og en krasjrapport ellers får du et grønt signal som sier at alt fungerer.

Selvfølgelig, tatt til sin logiske ekstrem, kan du også automatisere distribusjonen, oppsett automatisert A/B -testing og helhet fjerne menneskelig inngripen fra prosessen. Som betegnes som kontinuerlig levering og/eller kontinuerlig distribusjon avhengig av automatiseringsnivå. Men vi vil bare fokusere på kontinuerlig integrasjon i denne opplæringen.

Forutsetninger

Vi kommer til å fokusere på å sette opp en enkel CI -flyt i opplæringen ved hjelp av en Gitlab -forekomst over HTTPS som vi dekket i et tidligere innlegg.

I tillegg antar vi også at du har satt opp en brukerkonto i denne Gitlab -forekomsten og har et depot (klonet på din lokale maskin) administrert under brukernavnet ditt. Det er dette depotet som vi skal bruke for å demonstrere CI -arbeidsflyt. I opplæringen kommer navnet til det mitt prosjekt.

Å liste opp alt:

1. Gitlab -forekomst
2. Blank depot, kalt My-Project
3. Lokal klon av dette depotet
4. Din lokale Git -forekomst konfigurert for å skyve endringer i Fjernkontroll.

Opprette en enkel app

La oss lage en enkel node i dette depotet.JS -app. Denne appen er en enkel ekspress.JS Server som er ment å bli distribuert i en Docker -beholder. Serveren gir en HTTP -nyttelast som sier “Hello World” i nettleseren din.

I roten til ditt lokale depot, oppretter du en fil app.JS og legg til følgende linjer:

'bruk streng';
const express = krever ('ekspress');
// konstanter
const port = 8080;
const vert = '0.0.0.0 ';
// app
const app = express ();
app.få ('/', (req, res) =>
res.Send ('Hello World \ n');
);
app.Lytt (port, vert);
konsoll.Log ('Kjør på http: // $ host: $ port');

Opprett deretter en annen fil pakke.JSON og legg til følgende:

"Navn": "Docker_web_app",
"Versjon": "1.0.0 ",
"Beskrivelse": "Node.JS på Docker ",
"Forfatter": "John Doe",
"Main": "Server.JS ",
"skript":
"Start": "Nodeserver.JS "
,
"Avhengigheter":
"Express": "^4.16.1"

Til slutt, lage en Dockerfile og legg til følgende innhold i det:

Fra node: 8
# Opprett appkatalog
Workdir/usr/src/app
# Installer appavhengigheter
# Et jokertegn brukes til å sikre begge pakken.JSON og pakkelås.JSON er kopiert
Kopipakke*.JSON ./
Kjør NPM -installasjon
# Hvis du bygger koden din for produksjon
# Kjør npm install -bare = produksjon
# Bunt appkilde
KOPIERE…
Utsett 8080
CMD ["Node", "App"]

Byggprosessen for denne appen vil innebære å lage en nodebeholder og installere avhengighetene (som Express.JS -modul). Denne prosessen skal skje uten noen feil. For enkelhets skyld skal vi ikke diskutere noen testing i denne opplæringen.

Gitlab Runner Pipeline

Nå vil vi legge til en annen fil til vårt depot som vil bli kalt .Gitlab-ci.yml . Denne filen vil inneholde instruksjonene for å bygge vårt prosjekt. Nå, hver gang vi skyver en forpliktelse til vår Gitlab -forekomst, ville Gitlab påkalle en løper for å bygge og teste prosjektet.

Vi tildeler denne rørledningen forskjellige arbeidsplasser som kan kjøre alle sammen uavhengig av hverandre, noe som gjør byggeprosessen mer fleksibel. For ovennevnte repo er dette en gyldig .Gitlab-ci.yml Opprett denne filen i roten til depotet ditt:

Bilde: Node: Siste
stadier:
- bygge
cache:
Stier:
- node_modules/
install_avhengigheter:
Fase: Bygg
manus:
- NPM installasjon

Vi har bare ett trinn bygge Og det har bare NPM installasjon som et manus. Dette er en kommando du må kjøre manuelt hver gang en endring kommer til prosjektet ditt. Gitlab -løperen ville gjøre dette for deg. Runner kan installeres i en Kubernetes -klynge, en VPS i skyen eller i din lokale arbeidsstasjon, og hvis den er aktiv, vil den vente på instruksjoner fra Gitlab -serveren for å utføre en build.

Vi vil installere og konfigurere en løper lokalt for å automatisere den.

Få løpertokenet

Åpne opp depotet ditt på Gitlab, og besøk IT er CD/CI -innstillinger. Det er Innstillinger → CD/CI Inne i testlageret ditt.

Legg igjen Auto DevOps -innstillingen til standard og klikk på UTVIDE For å utvide de generelle rørledningsinnstillingene, og du vil bli vist en løpertoken. Kopier verdien og hold den selvfølgelig privat hvis du verdsetter prosjektet ditt.

Ved hjelp av dette tokenet vil din lokale Gitlab -løper kjørbar kunne registrere seg sikkert med Gitlab -forekomsten din.

Installere Gitlab -løperen

Gitlab-Runner er et lite lett program skrevet i Go som kjører CI -relatert arbeidsplasser På din lokale maskin og sender resultatene til Gitlab for at den skal vurdere endringene. Det er en enkelt kjørbar binær som kan installeres på ethvert større operativsystem. Følg instruksjonene her, for ditt spesielle operativsystem. Disse installasjonene varierer vilt, så det er umulig å liste opp alle.

Alternativt kan du bruke Runner som en Docker -tjeneste, men la oss bare holde oss til tradisjonell installasjon, for kommandoene er enklere å lese og forstå for leseren. Når du har den installert på din lokale arbeidsstasjon, må du utføre kommandoen:

$ gitlab-runner register

Dette vil stille deg flere spørsmål som begynner med din Gitlab-CI-koordinator som vil være din Gitlab-forekomst:

$ gitlab-runner register
Vennligst skriv inn Gitlab-CI-koordinator-URL (e.g. https: // gitlab.com/):
https: // gitlab.eksempel.com

Det vil da be om løpertokenet ditt, som vi fikk i forrige seksjon:

Vennligst skriv inn Gitlab-CI-symbolet for denne løperen:

Din_secret_token

Deretter for noen identifiserende beskrivelse, og du kan bare hoppe over å legge til alle tagger ved å treffe:

Vennligst skriv inn Gitlab-CI-beskrivelsen for denne løperen:

[Vertsnavn]: Demo for å sette opp CI ved hjelp av Runner

Vennligst skriv inn Gitlab-CI-kodene for denne løperen (komma atskilt):

Registrering av løper ... lyktes

Det viktigste er at det vil be deg om en eksekutor (mer om dette om et øyeblikk), vi vil velge Docker av hensyn til vårt eksempel.

Vennligst skriv ut eksekutoren: Docker-SSH+Machine, Kubernetes, Parallels, Shell, SSH, VirtualBox, Docker+Machine, Docker, Docker-SSH:

Docker

Base Docker -bildet som bygningen vil finne sted, og må spesifiseres i, vår eksempler -app bruker Node, slik at vi vil spesifisere et nodebilde:

Vennligst skriv inn standard Docker -bildet (e.g. Ruby: 2.1):

Node: Siste

Runner registrerte seg med hell. Start gjerne det, men hvis den allerede kjører, bør konfigurasjonen automatisk lastes på nytt!

Nå er noe som trenger en liten forklaring her Utførere? Måten CI -arbeid flyter er at bygningen av moduler, testing osv. Er kjent som arbeidsplasser og eksekutører utfører disse jobbene. Hvis du valgte VirtualBox som en eksekutor, ville Gitlab -løperen integrere seg med den lokalt installerte VirtualBox og kjøre CI -jobbene i en VM, hvis du velger Kubernetes, ville det skje i Kubernetes -klyngen, i skyen, hvis du velger Ssh du kan Delegere CI -oppgavene til en ekstern server.

Eksempelprosjektet vårt er basert på Docker, så det er fornuftig å bruke Docker som vår bøddel. Du må ha Docker installert lokalt for dette.

Å ha flere alternativer for eksekutører gjør løper mer fleksibel. Det kan være lurt å bygge lokalt fordi prosjektfilene er for store, eller det kan være lurt å utføre på en ekstern server med 20 kjerner og en halv terabyte RAM fordi byggeprosessen er beregningsintensiv, og spesifiserer et eksekutoralternativ gir deg den fleksibiliteten.

Til slutt, i skallet ditt, vil du starte løpertjenesten:

$ Gitlab-Runner Start

Ser .Gitlab-ci.YML i aksjon

Nå har vi gjort alle disse endringene i vår lokale repo opprettet hele appen.JS, pakke.Json, Dockerfile og .Gitlab-ci.YML -filer. Antagelig begikk du endringene i ditt lokale depot ved å løpe:

$ git scenefilnavn
$ git commit -m “Commit Message”

La oss skyve endringene til vår eksterne Gitlab.

$ git push -u opprinnelse

Du kan deretter åpne prosjektet ditt i Gitlab, gå til My-Project → Pipeline Og du vil se dette en tagg som sier "passert" ved siden av forpliktelsen du gjorde. Påfølgende forpliktelser, vil også ha tagger.

Så det er det grunnleggende om CI ved hjelp av Gitlab og Runner. Håper du likte innlegget og lærte noe nytt av det.