GitHub Actions og CI/CD — slik setter du opp automatisk deploy

Hva er CI/CD og hvorfor er det viktig?

Continuous Integration (CI) betyr at kode-endringer automatisk bygges og testes med en gang de pushes til repository. Målet er å oppdage integrasjonsfeil tidlig — ikke etter uker med parallelt arbeid. Continuous Delivery (CD) betyr at kode som passerer alle tester automatisk gjøres klar for deploy, og eventuelt deployres automatisk til produksjon (Continuous Deployment).

Uten CI/CD er situasjonen ofte slik: utviklere jobber i lange brancher, merger sjelden, og "merge hell" oppstår når mange endringer skal samles. Manuelle deploy-prosesser er sårbare for menneskelige feil og tar lang tid. Med CI/CD merger du mange ganger daglig, alle tester kjøres automatisk, og deploy skjer trygt og forutsigbart. Resultatet er høyere utviklingshastighet og færre produksjonsfeil.

GitHub Actions — grunnleggende begreper

GitHub Actions-workflows beskrives i YAML-filer lagret i .github/workflows/-mappen i repositoryet. En workflow er en automatisert prosess som kjøres ved bestemte hendelser (events). De viktigste elementene er: Workflow — den overordnede prosessen definert i én YAML-fil. Event — hva som trigger workflowen (push, pull_request, schedule, workflow_dispatch osv.). Job — en samling steg som kjøres på én runner (virtuell maskin). Step — en enkelt oppgave i en jobb, enten en shell-kommando eller en action. Runner — den virtuelle maskinen som kjører jobbene (GitHub tilbyr Ubuntu, Windows og macOS).

Actions er gjenbrukbare komponenter fra GitHub Marketplace. Populære actions inkluderer: actions/checkout (kloner repositoryet), actions/setup-node (installerer Node.js), docker/build-push-action (bygger og pusher Docker-image) og aws-actions/configure-aws-credentials (autentiserer mot AWS). Du kan også skrive egne actions.

Din første workflow — CI for et Node.js-prosjekt

Opprett filen .github/workflows/ci.yml i repositoryet ditt. En typisk Node.js CI-workflow ser slik ut:

name: CI / on: push: branches: [main, develop] / pull_request: branches: [main] / jobs: test: runs-on: ubuntu-latest / strategy: matrix: node-version: [18, 20, 22] / steps: - uses: actions/checkout@v4 / - name: Sett opp Node.js / uses: actions/setup-node@v4 / with: node-version: ${{ matrix.node-version }} / cache: npm / - run: npm ci / - run: npm test / - run: npm run build.

Denne workflowen kjøres på alle pushes til main og develop, og på alle pull requests til main. Den tester koden mot tre versjoner av Node.js parallelt. matrix: gjør det mulig å kjøre jobben med ulike konfigurasjoner samtidig. npm ci er foretrukket fremfor npm install i CI, da den er raskere og mer deterministisk — den installerer nøyaktig det som er i package-lock.json.

CD — automatisk deploy til produksjon

Et vanlig produksjonsoppsett er: kjør CI på alle branches, deploy til staging ved push til develop, deploy til produksjon ved push til main (etter godkjenning). Secrets (API-nøkler, passord) legges inn via GitHub → repository Settings → Secrets and variables → Actions, og refereres som ${{ secrets.MITT_SECRET }} i workflows.

Eksempel på deploy til en VPS med SSH: deploy-til-produksjon kjøres etter at tester er bestått (needs: test). Steget bruker appleboy/ssh-action med SSH-nøkkel fra secrets, logger inn på serveren og kjører: git pull, npm ci --production, pm2 restart app. For mer avansert deploy med Docker: bygg image, push til registeret (Docker Hub, GitHub Container Registry, AWS ECR), og deretter kjør docker pull + docker compose up på serveren.

For Kubernetes-deploy kan du bruke kubectl og sette opp KUBECONFIG som en secret. Deploy til AWS Elastic Beanstalk, Google Cloud Run, Azure App Service og Vercel har alle dedikerte GitHub Actions som forenkler hele prosessen til noen få linjer YAML.

Beste praksis for GitHub Actions-workflows

Bruk alltid pinned versions (actions/checkout@v4 ikke actions/checkout@latest) for reproduserbare og sikre builds. Konfigurer alltid caching av avhengigheter — det er den enkleste måten å halvere byggetiden på. For Node.js bruk cache: npm i actions/setup-node, for Docker brukes cache-from og cache-to i build-push-action.

Skill CI og CD i separate workflow-filer for klarhet. Bruk environments med required reviewers for produksjonsdeploy — dette tvinger en manuell godkjenning før produksjonsdeploy kjøres, selv om alt er automatisert. Environments er gratis for public repos og tilgjengelig i GitHub Team og Enterprise for private.

Unngå å lagre hemmeligheter i workflow-YAML-filer eller i koden — bruk alltid GitHub Secrets. Vurder OpenID Connect (OIDC) for autentisering mot skytjenester som AWS og GCP — dette eliminerer behovet for langtids-hemmeligheter og er sikrere. Sett opp branch protection rules på main som krever at CI passerer før merge.

Avanserte mønstre — reusable workflows og composite actions

Reusable workflows lar deg definere en workflow én gang og kalle den fra mange andre workflows. Dette er svært nyttig i monorepos eller organisasjoner med mange repositories som deler den samme CI/CD-logikken. Definer den kallbare workflowen med on: workflow_call: og kall den med uses: din-org/workflows/.github/workflows/ci.yml@main.

Composite actions lar deg pakke en serie steg inn i én gjenbrukbar action. Der du ellers måtte kopiere de samme 10 stegene mellom mange workflows, definerer du dem én gang i en action.yml-fil. Concurrency-settings er viktige: concurrency: group: ${{ github.workflow }}-${{ github.ref }} / cancel-in-progress: true avbryter pågående kjøringer av samme workflow på samme branch når en ny push kommer — dette sparer runner-minutter og gir raskere feedback.

"En god CI/CD-pipeline er det beste du kan investere i for et utviklingsteam. Ikke fordi det er avansert teknologi, men fordi det fjerner menneskelig feil og frigjør utviklere til å fokusere på det som skaper verdi."