Hvordan oppnår du deployments uten nedetid?

Question

Accepted Answer

**Zero-downtime deployment** betyr å gi ut nye versjoner uten noen avbrudd for brukere — applikasjonen forblir tilgjengelig hele tiden. For å oppnå det kreves nøye deploymentstrategier, bakoverkompatible endringer, helsesjekker og grasiøs håndtering av forespørsler som allerede er i gang.

## Hva zero-downtime krever

```text
GOAL: deploy a new version with NO user-facing downtime (always-available service):
  → never take the whole service offline to deploy
  → always have healthy instances serving while updating others
  → handle in-flight requests gracefully (don't drop them mid-request)
→ Combine several techniques (below).
```

## Viktige teknikker

```text
✓ DEPLOYMENT STRATEGY — rolling, blue-green, or canary (never all-at-once downtime):
  → rolling: update instances gradually (others keep serving)
  → blue-green: switch traffic to the new environment instantly
✓ LOAD BALANCER + HEALTH CHECKS → route traffic only to healthy/ready instances;
  new instances join only when READY (readiness checks)
✓ GRACEFUL SHUTDOWN → draining: stop sending new requests to an instance, let it FINISH
  in-flight requests, THEN stop it (handle SIGTERM) → no dropped requests
✓ BACKWARD-COMPATIBLE changes → old and new versions coexist during the rollout
  (API and DATABASE compatibility — expand-contract migrations)
```

## Databaseutfordringen

```text
⚠️ Schema changes during zero-downtime deploys are the hard part (old + new code run
   together): use BACKWARD-COMPATIBLE migrations (expand-contract / parallel change):
   add new schema → migrate → remove old in a LATER deploy → never break the running version
```

## Hvorfor det betyr noe

Å forstå hvordan man oppnår deployments uten nedetid er viktig kunnskap på seniornivå fordi **kontinuerlig tilgjengelighet under deployments er et nøkkelkrav for mange produksjonssystemer**, så det er verdifullt for pålitelig levering.

Mange systemer må være tilgjengelige 24/7, så å deploye uten å avbryte brukere (zero-downtime) er essensielt — å ta servicen offline for å deploye er uakseptabelt for slike systemer, spesielt gitt CIs hyppige deployments.

Å forstå hva zero-downtime **krever** (aldri å ta hele servicen offline, alltid ha friske instanser som serverer mens andre oppdateres, og håndtere forespørsler i gang grasiøst) rammer inn målet.

Å forstå de **viktige teknikkene** som kombineres for å oppnå det — bruk av **deploymentstrategier** som unngår all-på-en-gang nedetid (rolling, blue-green, canary), **load balancers med helse-/readiness-sjekker** (dirigere trafikk kun til friske, klare instanser slik at oppdaterte instanser ikke mottar trafikk og nye instanser slutter seg bare når de er klare), **grasiøs nedstengning/draining** (stoppe nye forespørsler til en instans, la den fullføre forespørsler i gang, deretter stoppe den — slik at ingen forespørsler blir droppet under flyten, krever riktig SIGTERM-håndtering), og **bakoverkompatible endringer** (slik at gamle og nye versjoner coexisterer under utrullingen) — er den praktiske kjernen.

Kritisk er det å forstå **databaseutfordringen** (skjemaendringer er den vanskelige delen av zero-downtime fordi gammel og ny kode kjører sammen, krever bakoverkompatible expand-contract-migrasjoner) som kobler seg til migrasjonskunnskapen som er essensielt for virkelig zero-downtime-deployments.

Disse teknikkene sammen muliggjør kontinuerlig deployment uten avbrudd for brukerne.

Siden kontinuerlig tilgjengelighet er et nøkkelkrav for mange produksjonssystemer og CI/CD deployer hyppig, og siden zero-downtime deployment krever kombinasjon av deploymentstrategier, helsesjekker, grasiøs nedstengning og spesielt bakoverkompatible (database) endringer, er forståelse av hvordan man oppnår deployments uten nedetid viktig kunnskap på seniornivå for pålitelig levering — en kritisk evne for alltid-tilgjengelige systemer, som reflekterer den operasjonelle sofistikering som forventes for seniorrollen ved deployment til produksjon uten å forstyrre brukerne.