Hvordan opnår du nul-nedetids-deployments?

Question

Accepted Answer

**Nul-nedetids-deployment** betyder at udgive nye versioner uden nogen afbrydelse for brugerne — applikationen forbliver tilgængelig gennem hele processen. For at opnå det kræves omhyggelige deploymentstrategier, baglæns-kompatible ændringer, sundhedstjek og elegant håndtering af igangværende requests.

## Hvad nul-nedetid kræver

```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).
```

## Vigtige 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)
```

## Database-udfordringen

```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 betyder noget

At forstå hvordan man opnår nul-nedetids-deployments er vigtig viden på seniorniveau, fordi **kontinuerlig tilgængelighed under deployments er et nøglekrav for mange produktionssystemer**, så det er værdifuldt for pålidelig levering.

Mange systemer skal være tilgængelige 24/7, så deployment uden at afbryde brugerne (nul-nedetid) er essentiel — at tage servicen offline for at deploye er uacceptabelt for sådanne systemer, især givet CI/CD's hyppige deployments.

At forstå hvad nul-nedetid **kræver** (aldrig at tage hele servicen offline, altid at have sunde instanser, der betjener trafikken mens andre opdateres, og elegant håndtering af igangværende requests) definerer målet.

At forstå de **vigtige teknikker**, der kombineres for at opnå det — brug af **deploymentstrategier**, der undgår all-at-once nedetid (rolling, blue-green, canary), **load balancers med sundhed/parathedstjek** (routing af trafik kun til sunde, parate instanser, så opdateringsinstanser ikke modtager trafik og nye instanser tilslutter sig kun når de er parate), **elegant shutdown/draining** (stop af nye requests til en instans, lad den afslutte igangværende requests, derefter stop den — så ingen requests droppes mid-flight, hvilket kræver ordentlig SIGTERM-håndtering), og **baglæns-kompatible ændringer** (så gamle og nye versioner eksisterer side om side under udrulningen) — er den praktiske kerne.

Vigtigt er det at forstå **database-udfordringen** (skemaændringer er den svære del af nul-nedetid, fordi gammel og ny kode køres sammen, hvilket kræver baglæns-kompatible expand-contract migrations) knytter sig til migrations-viden, som er essentiel for virkelig nul-nedetids-deployments.

Disse teknikker kombineres for at muliggøre kontinuerlig deployment uden nogen brugerfacing-afbrydelse.

Da kontinuerlig tilgængelighed er et nøglekrav for mange produktionssystemer og CI/CD deployer hyppigt, og da nul-nedetids-deployment kræver at kombinere deploymentstrategier, sundhedstjek, elegant shutdown og især baglæns-kompatible (database) ændringer, er forståelse af hvordan man opnår nul-nedetids-deployments vigtig viden på seniorniveau for pålidelig levering — en kritisk evne for altid-tilgængelige systemer, som afspejler den operationelle sofistikering, der forventes for seniorroles, der deployer til produktion uden at forstyrre brugerne.