Deploye

Deployering

Deployering handler om kontrollert flytting av et verifisert artefakt til kjøremiljøer. Målet er trygg utrulling, rask rollback og forutsigbar drift.
Sist endret 26.10.2026 Skrevet av Christoffer Hafsahl

Deployering starter etter at artefaktet er bygget og verifisert. Hovedprinsippet er at samme artefakt promoteres mellom miljøer, uten ny bygging underveis.

Denne artikkelen fokuserer på utrulling til miljøer. Selve pipeline-styringen er dekket i CI/CD, og detaljer om trygg artefaktproduksjon i Bygging.

CI/CD-flyt fra kodeendring til produksjon Utvikleren committer endringer fra utviklingsmiljøet til versjonskontrollen. Derfra starter utvikleren CI/CD-kjøringen, som bygger artefaktet på en byggeagent. Byggeagenten deployer til dev-miljøet, dev-miljøet videre til test, og fra test til produksjon kreves en godkjenning først. Utviklingsmiljø Committer endringer Versjonskontroll CI/CD starter Byggeagent Deployer til Dev Deployer til Test Krever godkjenning, deployer til Prod
CI/CD-flyten fra kodeendring til produksjon. Det samme artefaktet følger hele veien, og stoppunktet før produksjon er bevisst: hver kjøring skal kunne spores, gjentas og godkjennes før den når sluttbrukerne.

Prinsipper for trygg deploy

For å redusere drifts- og sikkerhetsrisiko bør deployprosessen bygge på:

  • Promotering av samme artefakt: Ikke bygg på nytt per miljø.
  • Verifikasjon før utrulling: Deploy skal stoppe dersom nødvendige kontroller ikke er bestått.
  • Automatisert og idempotent utrulling: Samme deploykommando skal gi samme resultat.
  • Sporbarhet: Hver utrulling skal kunne kobles til artefakt, commit og godkjenning.
Promotering av artefakt gjennom miljøene Det samme artefaktet rulles ut til dev, så til test og til slutt til produksjon. Før utrulling til test kreves en godkjenning, og før utrulling til produksjon kreves godkjenning fra fire øyne. Deploy til dev Godkjenning før deploy Deploy til test 4-øyne-godkjenning før deploy Deploy til prod
Samme artefakt promoteres mellom miljøene uten ny bygging underveis. Godkjenningene mellom hvert steg er det som skiller en promotering fra en ny utrulling — det er den samme koden som allerede er verifisert i miljøet før.

Hva en deployprosess bør dekke

En moden deployprosess bør minimum dekke:

  • Miljøforflytning (dev-test-prod): Tydelige gates mellom miljøer.
  • Godkjenning og endringskontroll: Krav til godkjenning før produksjon.
  • Release-strategi: Støtte for blue/green, canary eller rolling deploy der det er hensiktsmessig.
  • Rollback: Definert og testet prosedyre for rask reversering.
  • Smoke-tester etter deploy: Verifiser at løsningen faktisk fungerer i målmiljøet.
  • Observabilitet: Overvåkning og varsling som fanger feil tidlig etter utrulling.

Tilgangsstyring og miljøsikkerhet

Deploy-tilgang må behandles som en privilegert operasjon:

  • Minst privilegie for deploy-identiteter: Gi kun tilgangene som er nødvendige for utrulling.
  • Skille mellom roller: Skille roller for utvikling og produksjonsutrulling der det er mulig.
  • Begrens trigging av produksjonsdeploy: Begrens hvem som kan starte deployering til produksjon.
  • Sporbarhet på utrullinger: Logg hvem som deployet hva, når og til hvilket miljø.

Deploy av KI-systemer

For KI-løsninger må deployprosessen også håndtere modellatferd og datadrevet risiko:

  • Modellutrulling med kontroll: Bruk gradvis utrulling (for eksempel canary) for å redusere konsekvens ved feil modelloppførsel.
  • Tydelig versjonskobling: Kjørende løsning skal kunne kobles til eksakt modellversjon, kodeversjon og konfigurasjon.
  • Verifisering i målmiljø: Kjør relevante kvalitets- og sikkerhetssjekker også etter deploy, ikke bare i bygg.
  • Driftsovervåkning: Følg med på modellkvalitet, responstid og eventuelle tegn til drift i data eller output.
  • Rask tilbakeføring: Ha klar prosedyre for å bytte tilbake til tidligere modellversjon ved avvik.

Veien videre