Enkel guide til GitLab CI/CD: slik bygger du en nyttig pipeline steg for steg

GitLab CI/CD kan se overveldende ut første gang du åpner .gitlab-ci.yml, men du trenger ikke en komplisert enterprise-pipeline for å få mye igjen. Med noen få gjennomtenkte steg kan du automatisere bygg, sjekker og utrulling på en måte som sparer tid og reduserer feil.

I denne guiden går vi gjennom hvordan du setter opp en jordnær, nyttig GitLab-pipeline som ligner på det mange mindre og mellomstore team bruker i reelle prosjekter. Fokus er på forståelse, struktur og typiske fallgruver, ikke avansert magi.

Hva GitLab CI/CD egentlig gjør for deg

GitLab CI/CD er en innebygd motor som kjører jobber når noe skjer i prosjektet ditt: push til en branch, merge request, tag eller en planlagt tid. Hver jobb kjører i et eget miljø (en “runner”), som du beskriver med enkel YAML.

Poenget er å gjøre ting som du ellers ville gjort manuelt: kjøre analyser, bygge artefakter, kjøre automatiserte sjekker, pakke applikasjonen og eventuelt sende den videre til et miljø for intern test eller produksjon.

Grunnstrukturen i en .gitlab-ci.yml

Filen .gitlab-ci.yml ligger i rotmappen i repoet og beskriver hele oppsettet. Selv et lite oppsett bør ha noen faste byggesteiner: globale innstillinger, stages, jobber og regler for når jobbene skal kjøre.

En enkel start kan se slik ut:

Eksempel:

stages:
- build
- test
- deploy

variables:
NODE_ENV: "test"

build_app:
stage: build
script:
- echo "Bygger..."

run_tests:
stage: test
script:
- echo "Kjører sjekker"

Velg riktig type runner: delt, egen eller lokal

GitLab-jobber kjører ikke av seg selv, de trenger en runner. På GitLab.com finnes ofte delte runners tilgjengelig, men i mange bedriftsoppsett brukes egne runners, for eksempel Docker-baserte på en server eller Kubernetes.

Hvis pipelinen din aldri starter, er en vanlig årsak at prosjektet ikke har tilgang til noen runner, eller at den er feil konfigurert. Sjekk prosjektinnstillinger og at runneren er tagget riktig hvis du bruker runner-tags i jobbene.

Bygg en enkel “build og sjekk” pipeline

Et nyttig utgangspunkt er en pipeline som gjør tre ting: installerer avhengigheter, bygger prosjektet og kjører grunnleggende sjekker. Dette kan ofte samles i to eller tre jobber, avhengig av hvor mye du vil gjenbruke mellom stegene.

Et typisk mønster er å ha en “build”-jobb som lager et artefakt, og en “analyse”- eller “test”-jobb som konsumerer dette artefaktet for videre sjekker, i stedet for å gjøre alt på nytt hver gang.

Bruk Docker-image bevisst

De fleste jobber definerer et image, for eksempel et offisielt språkimage fra Docker Hub. Valg av image har stor innvirkning på både hastighet og stabilitet, så det lønner seg å være eksplisitt i stedet for å bruke generiske eller “latest”-tagger.

Hvis du merker at pipeline-tiden varierer mye, kan det hjelpe å velge et slankere image, cache pakker effektivt eller legge til verktøy direkte i et eget custom-image som dere bruker på tvers av prosjekter.

Cache og artefakter: spar tid uten å bryte alt

Cache og artefakter forveksles ofte. Cache brukes til å gjenbruke ting mellom jobber og pipeline-kjøringer, typisk pakker fra en pakkebehandler. Artefakter brukes til å dele genererte filer mellom jobber i samme pipeline, som bygde binærer eller kompilert frontend.

En enkel start for cache kan se slik ut:

cache:
key: "$CI_COMMIT_REF_SLUG"
paths:
- node_modules/

Hvis du får merkelige feil etter endringer i avhengigheter, kan problemet ligge i en for aggressiv cache. Da kan du tømme cache fra GitLab-grensesnittet eller endre nøkkelen slik at det bygges på nytt.

Begrens når jobber kjører med rules

Uten regler kjører jobbene på alle pushes, som sjelden er ønskelig i litt større prosjekter. Med rules kan du for eksempel kjøre utrulling kun ved tagger, eller bare kjøre visse sjekker på merge requests.

Et enkelt mønster kan være:

• Full pipeline på merge requests til hovedbranch
• Enklere pipeline på vanlige feature-branches
• Utrulling kun når du tagger en versjon

Dette gir mer kontroll på ressursbruken og kortere feedback der det er viktigst.

En enkel “deploy til test”-jobb

Når bygg og sjekker er på plass, er neste naturlige steg å sende en versjon til et testmiljø. Oppsettet er veldig forskjellig fra prosjekt til prosjekt, men strukturen i GitLab-pipen er ofte den samme: hent artefakt, logg inn mot en tjeneste og kjør et utvalgt skript.

Et trygt mønster er å ha en egen jobb for intern utrulling med tydelig miljønavn, for eksempel environment: name: staging, og å kreve manuelt godkjenning via when: manual hvis du vil unngå at alt går automatisk ut.

Vanlige feil som er enkle å unngå

Mye frustrasjon i GitLab CI stammer fra noen få gjengangere: feil innrykk i YAML, misforståtte variabler og glemte paths i artefakter eller cache. Bruk YAML-valideringen i GitLab og start med kortere filer før du drar inn maler og inkluderer.

En enkel sjekkliste ved trøbbel er nyttig:

• Sjekk at .gitlab-ci.yml validerer uten feil
• Se på komplette jobblogger i GitLab, ikke bare statusikonet
• Bekreft at riktig runner er tilknyttet prosjektet
• Logg ut miljøvariabler du er usikker på i en midlertidig jobb

Slik bygger du gradvis videre uten å miste oversikten

Det mest bærekraftige er å starte lite og bygge videre i små steg. Først en ren “build og sjekk”-pipeline, deretter cache, artefakter og en enkel utrulling til testmiljø. Til slutt kan du bryte ting opp i gjenbrukbare maler og egne filer ved behov.

Hvis du merker at .gitlab-ci.yml begynner å bli uoversiktlig, er det et tegn på at du enten bør rydde i navngivning og struktur eller ta i bruk include for å dele opp felles oppsett på tvers av prosjekter. Poenget er å gjøre filen lett å forstå for neste person som skal endre pipelinen.