Sådan konfigureres CI på GitLab ved hjælp af Docker

Et eksempel ved hjælp af Docker til at teste og bygge din pipeline

I fortiden har du måske prøvet forskellige værktøjer til at styre implementeringen af ​​dine applikationer effektivt. I denne tutorial vil jeg vise dig en hurtig og nem måde at konfigurere kontinuerlig integration til dit miljø ved hjælp af GitLab og Docker. Så lad os komme i gang.

Dette er, hvad vi skal konfigurere:

  • Versionskontrol
  • Udgave Tracker
  • Dokumentation
  • Kontinuerlig integration
  • Kontinuerlig levering
  • Repository (artefakter / docker-billeder)

Værktøjer som Jenkins er gode til kontinuerlig integration og levering. Mantis hjælper med sporing af problemer. Men for at forbedre effektiviteten og kvaliteten af ​​vores projekt, er vi nødt til at samle alle disse værktøjer. F.eks. Ønsker vi måske, at en git commit tilslutter sig eksisterende problemer, eller udløser en automatiseret test efter at have skubbet forpligtelser til mastergrenen.

Normalt leverer de fleste værktøjer allerede ud af boksen-integration med andre almindelige tjenester, men det er stadig svært at konfigurere dem til tider. Derudover ville arbejdsgangen være brudt, hvis en af ​​tjenesterne i kæden falder. Så det ville være dejligt, hvis der var en enkelt platform, der kunne opfylde alle disse krav, og det er derfor, vi har valgt GitLab.

GitLab CI

GitLab.com er en SAAS-baseret tjeneste, hvor du kan være vært for dit Git-lager, spore problemer og skrive wiki i markdown. Med GitLab CI kan du også konfigurere kontinuerlig integration ved hjælp af ethvert Docker-billede, der er tilgængeligt på Docker Hub. Lad os se på følgende eksempel.

GitLab CI YML

GitLab CI bruger en YAML-fil .gitlab-ci.yml til at definere projektkonfigurationen, som inkluderer en definition af alle de trin, der skal køres, efter at en CI / CD-rørledning er udløst som svar på en git push / merge. I dette eksempel har vi et simpelt Node.js-projekt, og vi vil gerne sikre, at koden er god ved at fnise og køre en enhedstest. For at spille sammen, gaffel dette lager og tjek det.

I ovenstående YAML-konfigurationsfil definerede vi 3 trin. Hvert trin er kun en gulp-opgave defineret i gulpfile.js. Alle kunne køre opgaven lokalt, så længe Node.js er installeret. Men i GitLab CI behøver vi kun at nævne, hvilket Docker-billede der er behov for. I vores tilfælde er det knudepunkt: 6.11.2. Desuden kunne denne billedattribut defineres inden for scenedefinitionen, så du kunne bruge forskellige værktøjer til hvert trin.

Scenedefinitionen

Lad os tage et dybere kig i scenedefinitionen.

Attributterne for before_script og script kan have flere værdier (array i .yml). Og hvis scriptudførelsen mislykkes, klassificeres scenen som mislykket.

Træk pipeline ud

Foretag bare nogle ændringer på mastergrenen, og du kan finde rørledningen, der kører på siden CI / CD -> Rørledning.

Rørledningens historie

Se scenen i detaljer

Klik på en bestemt pipeline, så kan du læse konsoloutputet for hvert trin. Dette er nyttigt, når scenen / jobbet mislykkes.

Scenens output

Fordelene ved at bruge GitLab CI sammen med Docker

Forskellige projekter kan kræve forskellige afhængigheder såsom Node.js, Ant, Maven. Tidligere, når jeg bruger et værktøj som Jenkins, skulle jeg sørge for, at alle disse er installeret på serveren. Ved at bruge Docker kan udvikleren referere til afhængigheder, der er tilgængelige på Docker Hub, uden at bede serveradministratoren om at konfigurere sådanne afhængigheder på serveren hver gang. Faktisk har Jenkins også en pipeline-plugin, og det kunne arbejde med Docker for at tjene nøjagtigt det samme formål. Men der kræves en ekstra indsats for at integrere Jenkins med versionskontrol, og som jeg nævnte før.

Selvom jeg foretrækker at bruge GitLab CI, betyder det ikke, at det helt kan erstatte Jenkins. Jenkins tilbyder en konfigurerbar brugergrænseflade, som er praktisk for ikke-udviklere, såsom QA, til at udføre visse opgaver såsom implementeringer og integrationstest.

Vælg et passende værktøj - det behøver ikke at være perfekt

Nøglen handler ikke om at vælge det perfekte værktøj. I stedet handler det mere om de mennesker, der bruger det. Før du søger efter et nyt værktøj, skal du prøve at identificere det problem, du først vil løse.

- Oprindeligt postet på Boatswain Blog.