GitHub Actions og CI/CD — den komplette norske guiden

Hva er CI/CD og hvorfor trenger du det?

CI/CD står for Continuous Integration og Continuous Delivery (eller Deployment). CI handler om å automatisk bygge og teste koden din hver gang noen pusher endringer. CD handler om å automatisk levere den testede koden til staging- eller produksjonsmiljøer. Sammen eliminerer de det som utviklere kaller "integrasjonshelvete" — der kode som fungerer lokalt kræsjer i produksjon fordi ingen hadde testet at alle delene passet sammen.

GitHub Actions er Microsofts/GitHubs svar på CI/CD, bygget direkte inn i GitHub. Fordelen er at du ikke trenger separate verktøy som Jenkins, CircleCI eller Travis CI — alt er integrert med repositoryet ditt. En typisk norsk startup-utvikler kan sette opp en komplett pipeline på under en time.

Kjernekonsepter — workflow, job, step og runner

En GitHub Actions workflow er en automatisert prosess definert i en YAML-fil under mappen `.github/workflows/` i repositoryet ditt. En workflow utløses av en trigger — for eksempel `push` til main, `pull_request`, eller en `schedule` (cron-jobb). En workflow inneholder én eller flere jobs. Jobs kjøres som standard parallelt, men kan konfigureres til å kjøre sekvensielt med `needs`. Hvert job kjører på en runner — en virtuell maskin (GitHub tilbyr Ubuntu, Windows og macOS). Inne i hvert job har du steps — individuelle kommandoer eller gjenbrukbare actions fra Marketplace.

• workflow — hele automatiseringsprosessen, definert i én YAML-fil
• trigger (on:) — hva som starter workflowen (push, PR, cron, manuelt)
• job — én gruppe med steps som kjører på én runner
• runner — virtuell maskin som kjører jobbet (ubuntu-latest, windows-latest, macos-latest)
• step — én enkelt oppgave: kjør kommando eller bruk en action
• action — gjenbrukbar enhet fra Marketplace (f.eks. actions/checkout@v4)
• artifact — filer produsert av workflowen (bygde filer, testrapporter)

Typisk pipeline — fra lint til produksjon

En veletablert pipeline for et Node.js-prosjekt ser gjerne slik ut: Steg 1 (lint) kjører ESLint for å sikre kodekvalitet. Steg 2 (test) kjører enhetstester med Jest eller Vitest. Steg 3 (build) kompilerer TypeScript og bygger produksjonsversjonen. Steg 4 (deploy) sender den bygde versjonen til Vercel, Netlify eller en egendriftet server. Hvert steg kjører kun hvis det forrige lyktes.

En minimal workflow-fil kan se slik ut i YAML: Du definerer `on: push: branches: [main]`, deretter et job kalt `pipeline` som kjører på `ubuntu-latest`. Steps starter med `uses: actions/checkout@v4` for å hente koden, deretter `uses: actions/setup-node@v4` med `node-version: 20`, deretter `run: npm ci` for å installere avhengigheter, `run: npm run lint`, `run: npm test` og til slutt `run: npm run build`. Disse seks stegene utgjør en komplett grunnleggende CI-pipeline.

Caching — spar minutter og penger

Uten caching installerer GitHub Actions alle npm-pakker fra scratch ved hvert pipeline-kjøring. For et prosjekt med 500 avhengigheter kan dette ta 2–3 minutter. Med caching av `node_modules`-mappen basert på en hash av `package-lock.json` reduseres dette til 10–20 sekunder ved cache-treff. Bruk actions/cache@v4 og cache nøkkelen `${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}`. GitHub lagrer cache i 7 dager og gir deg inntil 10 GB cache-lagring gratis per repository.

Secrets og miljøvariabler — trygg håndtering av sensitiv info

Aldri legg API-nøkler, passord eller tokens direkte i YAML-filer. GitHub Actions har et innebygd secrets-system: gå til repository-innstillinger → Secrets and variables → Actions, og legg til secrets der. I workflow-filen refererer du til dem som `${{ secrets.MIT_API_NOKKEL }}`. Secrets skrives aldri ut i logger — GitHub maskerer dem automatisk.

For miljø-spesifikke verdier (ulike secrets for staging vs. produksjon) bruk GitHub Environments. Du kan sette opp et `staging`-miljø og et `production`-miljø med ulike secrets, og i tillegg kreve manuell godkjenning fra en reviewer før deployment til produksjon skjer. Dette er beste praksis for seriøse prosjekter og oppfyller mange revisorers krav til separasjon av rettigheter.

Praktiske eksempler for norske utviklere

Et svært nyttig eksempel: automatisk deployment til Vercel. Legg til `VERCEL_TOKEN`, `VERCEL_ORG_ID` og `VERCEL_PROJECT_ID` som secrets, og bruk `amondnet/vercel-action@v25` i et deploy-step. Nå deployeres alle endringer til main automatisk til Vercel, med preview-URL-er for pull requests.

Et annet nyttig eksempel for norske teams: automatisk oppretting av GitHub-issue hvis pipeline feiler på main-branchen. Bruk `peter-evans/create-issue-from-file@v5` og et betinget step med `if: failure()`. Da slipper du å manuelt overvåke pipelinen — den varsler deg selv om noe er galt. Disse enkle automatiseringene kan spare et 5-personers team for 2–3 timer i uken med manuell oppfølging.