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 hver gang noen pusher endringer. CD handler om å automatisk levere den testede koden til staging- eller produksjonsmiljøer. Sammen fanger de opp feil tidlig, før kode som fungerer lokalt, havner i produksjon uten at noen har testet at alle delene passer sammen.

GitHub Actions er GitHubs innebygde plattform for CI/CD. Workflows defineres i selve repositoryet og kan startes av hendelser, manuelt eller etter en tidsplan, så du trenger ikke et separat verktøy som Jenkins, CircleCI eller Travis CI. For private repositories på GitHub Free får du 2 000 gratis minutter per måned og 500 MB artifact-lagring, mens bruk av standard GitHub-hostede runnere er gratis i offentlige repositories.

Kjernekonsepter — workflow, job, step og runner

En GitHub Actions-workflow er en automatisert prosess definert i en YAML-fil i mappen `.github/workflows` i repositoryet. En workflow utløses av en hendelse, for eksempel `push`, `pull_request` eller en `schedule` (cron). En workflow inneholder én eller flere jobs, og som standard har jobs ingen avhengigheter og kjører parallelt; med `needs` venter en job på at en annen er ferdig. Hver job kjører på en runner — GitHub tilbyr runnere med Ubuntu Linux, Microsoft Windows og macOS, og hver kjøring skjer i en nyopprettet virtuell maskin. Inne i hver job har du steps: enten et skript du har skrevet, eller en gjenbrukbar action.

• 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, ofte fra Marketplace (f.eks. actions/checkout@v7)
• artifact — filer produsert av workflowen (bygde filer, testrapporter)

Typisk pipeline — fra lint til produksjon

En vanlig pipeline for et Node.js-prosjekt ser gjerne slik ut: Steg 1 (lint) kjører for eksempel 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 egen server. Når stegene ligger i samme job, stopper jobben ved første steg som feiler, og deploy-jobben kan vente på de andre med `needs`.

En minimal workflow-fil kan se slik ut i YAML: Du definerer `on: push: branches: [main]`, deretter en job kalt `pipeline` som kjører på `ubuntu-latest`. Steps starter med `uses: actions/checkout@v7` for å hente koden, deretter `uses: actions/setup-node@v7` med `node-version: 24`, 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 laster hver kjøring ned alle avhengigheter på nytt, fordi hver jobb starter i en ny virtuell maskin. Den enkleste løsningen er den innebygde cachen i setup-actionene: setup-node cacher for npm, Yarn og pnpm, setup-python for pip, pipenv og Poetry, og setup-java for Gradle og Maven — for npm holder det å legge til `cache: 'npm'` under `setup-node`. Vil du styre selv, bruker du actions/cache@v6 med en nøkkel som `${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}`, slik at cachen fornyes når låsefilen endres. GitHub fjerner cache-oppføringer som ikke er brukt på over 7 dager, og samlet cache per repository er som standard begrenset til 10 GB; bruk utover dette faktureres.

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 Settings → Secrets and variables → Actions i repositoryet og legg til en ny repository secret. I workflow-filen refererer du til dem som `${{ secrets.MIT_API_NOKKEL }}`. GitHub maskerer secrets i loggene, men verdier som ikke er GitHub-secrets må du maskere selv med `::add-mask::`, og du bør passe på at ingen steg skriver ut secrets.

For miljøspesifikke verdier (ulike secrets for staging og produksjon) bruker du GitHub Environments. Du kan sette opp et `staging`-miljø og et `production`-miljø med ulike secrets, og kreve at bestemte personer eller team godkjenner jobber som bruker miljøet, med inntil seks reviewere. Merk at på GitHub Free, Pro og Team er required reviewers bare tilgjengelig for offentlige repositories.

Praktiske eksempler for norske utviklere

Et nyttig eksempel er automatisk deployment til Vercel. Vercels egen guide legger `VERCEL_TOKEN`, `VERCEL_ORG_ID` og `VERCEL_PROJECT_ID` inn som GitHub-secrets og bruker Vercel CLI direkte med kommandoene `vercel pull`, `vercel build` og `vercel deploy --prebuilt`, med én workflow for preview-deployments fra andre brancher enn main og én for produksjon.

Et annet nyttig eksempel er automatisk oppretting av et GitHub-issue hvis pipelinen feiler på main-branchen. Bruk `peter-evans/create-issue-from-file@v6` i et betinget step med `if: failure()`. Da slipper du å overvåke pipelinen manuelt — den varsler selv når noe er galt.