GitLab CI for webutviklere: enkel pipeline fra commit til deploy

Mange webutviklere kommer til et punkt der man har for mange manuelle steg: kjøre tester, bygge frontenden, logge inn på server, laste opp filer og håpe at ingenting ble glemt. Da er det lett å gjøre feil, og enda lettere å utsette viktige forbedringer.

GitLab CI kan automatisere mye av dette uten at du trenger å bli DevOps-ekspert. Med noen få filer i repoet ditt kan du gå fra tilfeldig kaos til en forutsigbar flyt fra commit til deploy.

Hva er GitLab CI og når gir det mening å ta det i bruk?

GitLab CI er den innebygde plattformen i GitLab for å kjøre automatiske jobber når det skjer noe i repoet ditt. Typiske ting er å kjøre tester, bygge assets, generere dokumentasjon eller rulle ut ny kode til et miljø.

For et vanlig webprosjekt kan du for eksempel la GitLab CI kjøre npm test og npm run build på hver merge request, og kun deploye til produksjon når main-branchen er grønn. Det gjør det enklere å se om en endring er trygg å sende videre.

De viktigste byggesteinene i en enkel pipeline

Grunnkonfigurasjonen ligger i en fil som heter.gitlab-ci.ymli rotmappen på repoet. Filen beskriver hvilke jobber som skal kjøre, i hvilken rekkefølge og på hvilke grener.

Fire begreper går igjen:

• Stages: logiske steg, for eksempel test, build og deploy.
• Jobs: konkrete oppgaver i en stage, for eksempel unit_tests eller deploy_production.
• Runner: maskinen som faktisk kjører jobben. GitLab kan tilby delte runners, eller du kan ha egne.
• Artifacts: filer som sendes videre mellom jobber, typisk bygde assets.

Eksempel: enkel pipeline for et frontendprosjekt

La oss ta et konkret eksempel med et Node-baserte frontendoppsett (React, Vue eller lignende) der du vil kjøre tester, bygge og så lagre bygget som artifact. Dette er en enkel .gitlab-ci.yml som viser strukturen:

Eksempel:

stages:
- test
- build

variables:
NODE_ENV: test

cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/

test_job:
stage: test
image: node:18
script:
- npm ci
- npm test

build_job:
stage: build
image: node:18
script:
- npm ci
- npm run build
artifacts:
paths:
- dist/
expire_in: 1 week


Her skjer det tre viktige ting: test og build er skilt i egne steg, node_modules-cachen gjør at pipeline går raskere, og bygde filer i dist-mappen ligger som artifacts du kan laste ned eller bruke i en senere deploy-jobb.

Hvordan koble dette mot miljøer og deploy

For å gjøre pipeline virkelig nyttig bør den ha minst ett miljø, for eksempel staging. GitLab har innebygd støtte for environments, som gir deg historikk på deploys og mulighet til å rulle tilbake.

Et enkelt oppsett for en statisk side som deployes til en server via rsync kan se slik ut:

deploy_staging:
stage: deploy
image: alpine:latest
dependencies:
- build_job
before_script:
- apk add --no-cache openssh-client rsync
script:
- mkdir -p ~/.ssh
- echo "$STAGING_SSH_KEY" > ~/.ssh/id_rsa
- chmod 600 ~/.ssh/id_rsa
- rsync -avz --delete dist/ user@staging-server:/var/www/html/
environment:
name: staging
url: https://staging.example.com
only:
- develop


Her leses en SSH-nøkkel fra et variabel, dist-artifacten fra build_job brukes, og deploy skjer kun fra develop-branchen. Produksjon kan ha en tilsvarende jobb som bare kjører fra main, gjerne med manual: true slik at noen må trykke på en knapp i GitLab før det skjer.

Håndtering av hemmeligheter og miljøvariabler

Det er fristende å legge nøkler og passord i .gitlab-ci.yml når du tester lokalt, men det bør unngås. Legg hemmeligheter iCI/CD variablesi prosjektinnstillingene i GitLab i stedet.

Du kan for eksempel definere STAGING_SSH_KEY, API_URL eller SENTRY_DSN der. Disse er tilgjengelige som miljøvariabler i jobbene dine, og du slipper å risikere at sensitive data havner i repoet.

Typiske feil og hvordan unngå dem

Noen gjengangere dukker opp når man startet med GitLab CI. Heldigvis er de enkle å identifisere hvis du vet hva du skal se etter.

Tre vanlige problemer:

• Feil filnavn: .gitlab-ci.yml må ligge i rotmappen og være gyldig YAML. Små formateringsfeil kan stoppe hele pipeline.
• Ingen runner: hvis du ikke har tilgang til en delt runner, må du sette opp en selv. Se prosjektets CI/CD-side for status.
• Sirkulær avhengighet: bruk dependencies nøye, og unngå at jobber refererer til hverandre på kryss og tvers.

En enkel sjekkliste før du skrur på CI for alvor

For å slippe mye feilsøking kan du gå gjennom en kort sjekkliste hver gang du innfører eller endrer en pipeline:

• Har du en liten, rask test-jobb som kjører på alle grener?
• Skiller du klart mellom test, build og deploy i stages?
• Er hemmeligheter kun i CI/CD variables, ikke i repoet?
• Er deploy begrenset til riktige grener, og helst manuelt for produksjon?
• Har du testet endringen i .gitlab-ci.yml med en egen testgren før du merger?

Når denne grunnstrukturen er på plass, kan du gradvis legge til mer: linting, visuelle tester, database-migreringer eller automatiske forhåndsvisninger for merge requests.

Veien videre: start smått og bygg på det som fungerer

Det viktigste er å ikke gape over for mye på første forsøk. En enkel pipeline som kun kjører tester på hver commit gir rask verdi, og du kan bygge videre derfra.

Etter noen uker vil du ofte oppdage repeterende manuelle steg som kan flyttes inn i GitLab CI. Da vet du at du automaserer de riktige tingene: det som faktisk sparer tid, reduserer feil og gjør hverdagsutviklingen mer forutsigbar.