Hvordan håndterer du databasemigrasjoner i CI/CD?

Question

Accepted Answer

**Databasemigrasjoner** (skjemaendringer) er en av de vanskeligste delene av CI/CD — ulikt tilstandsløs applikasjonskode holder databaser **tilstand** som ikke bare kan erstattes eller rulles tilbake. Å håndtere migrasjoner forsvarlig (automatisering, bakoverkompatibilitet, sikre mønstre) er essensielt for pålitelige utplasseringer.

## Hvorfor databasemigrasjoner er vanskelige

```text
App code is stateless (replace it, roll back freely). DATABASES hold STATE:
  → can't just "roll back" a migration that dropped a column or transformed data
    (the data may be gone) → rollbacks are risky/impossible for destructive changes
  → during deployment, OLD and NEW app code may run SIMULTANEOUSLY (rolling deploy) —
    both must work with the database schema at that moment
→ Schema changes need careful coordination with code deployment.
```

## Automatisere migrasjoner i pipelinen

```text
→ Migrations defined as CODE (versioned migration files; Flyway, Liquibase, ORM tools)
→ Run migrations as a pipeline STEP (apply pending migrations on deploy)
→ Migrations are versioned and applied in order, idempotently
→ Test migrations in staging before production
```

## Sikre migrasjonsmønstre (bakoverkompatibilitet)

```text
KEY PRINCIPLE: make migrations BACKWARD-COMPATIBLE so old AND new code both work during
the transition. Use the EXPAND-CONTRACT (parallel change) pattern:
  1. EXPAND → add the new schema (e.g. add a new column) — old code still works
  2. MIGRATE → deploy code that writes to both / reads new; backfill data
  3. CONTRACT → once all code uses the new schema, remove the old (in a LATER deploy)
→ NEVER drop/rename in the same deploy that needs it gone — split across deploys.
→ This enables zero-downtime deploys and safe rollbacks.
```

## Hvorfor det betyr noe

Å forstå hvordan man håndterer databasemigrasjoner i CI/CD er viktig fordi **migrasjoner er en av de vanskeligste og mest risikofylte delene av automatisert utplassering**, så det er verdifull praktisk kunnskap for pålitelig leveranse.

Kjerneutfordringen er at, ulikt tilstandsløs applikasjonskode (som kan erstattes og rulles tilbake fritt), **holder databaser tilstand** — så en migrasjon som sletter en kolonne eller transformerer data **kan ikke bare rulles tilbake** (dataene kan være borte), som gjør destruktive endringer risikofylt eller irreversibel, og under rullende utplasseringer **kjører gammel og ny kode samtidig**, begge må fungere med skjemaet på det øyeblikket.

Dette gjør at skjemaendringer krever nøye koordinering, ulikt resten av CI/CD.

Å forstå hvordan man **automatiserer migrasjoner** (definerer dem som versjonert kode via verktøy som Flyway, Liquibase, eller ORM-migrasjoner, kjører dem som et pipelinetrinn som anvendes i rekkefølge og idempotent, og tester i staging først) bringer migrasjoner inn i den automatiserte pipelinen på en sikker måte.

Mest viktig er det å forstå **sikre migrasjonsmønstre** — gjør migrasjoner **bakoverkompatible** så gammel og ny kode begge fungerer under overgangen, bruk **expand-contract-mønsteret (parallell endring)** (expand: legg til nytt skjema uten å bryte gammel kode; migrate: overfør kode og backfill data; contract: fjern gammelt skjema i en senere utplassering) og **aldri slette/omdøpe i samme utplassering som trenger det borte** — er nøkkelferdigheten som muliggjør **nedetidsfri utplasseringer og sikre tilbakekoblingspunkter** til tross for databasenes tilstandsfylte natur.

Dette er genuint vanskelig, viktig reell verden-kunnskap som skiller de som kan utplassere databasendringer på en sikker måte fra de som forårsaker nedetid eller datatap.

Fordi databasemigrasjoner er en vanskelig, risikofylt, uunngåelig del av å utplassere applikasjoner med databaser, og fordi å håndtere dem forsvarlig (automatisering plus bakoverkompatible expand-contract-mønstre) er essensielt for pålitelige, nedetidsfri utplasseringer, er det å forstå databasemigrasjoner i CI/CD verdifull, praktisk-viktig kunnskap — adressering av en av de vanskeligste aspektene ved kontinuerlig levering og refleksjon av mognheten som trengs for å utplassere tilstandsfylte applikasjoner på en sikker måte.