Hvad er deployment-miljøer (dev, staging, production)?

Question

Accepted Answer

Software udrulles typisk gennem flere **miljøer** — såsom **udvikling**, **staging** og **produktion** — som hver har et formål i processen fra kode til live-brugere. Når man promoverer kode gennem miljøer, opdages problemer før de når til rigtige brugere.

## De typiske miljøer

```text
DEVELOPMENT (dev) → where developers build and test (local or a shared dev environment);
  unstable, frequent changes, experimentation
STAGING (test/QA/pre-prod) → a PRODUCTION-LIKE environment for final testing:
  → mirrors production (same config/infrastructure as closely as possible)
  → run integration/E2E tests, QA, UAT before releasing
  → catch issues in a safe, prod-like setting BEFORE real users see them
PRODUCTION (prod) → the LIVE environment serving real users:
  → stability is critical; changes are careful and monitored
```

## Promovering gennem miljøer

```text
Code flows through environments, gaining confidence at each:
  dev → staging → production
  → tested in dev, verified in prod-like staging, then released to production
  → each environment is a GATE catching issues before the next
→ CI/CD pipelines AUTOMATE this promotion (deploy to staging, then prod).
```

## Hvorfor flere miljøer?

```text
✓ Catch issues BEFORE production (test in staging, not on real users)
✓ ISOLATION — experiment/break dev without affecting production or users
✓ Realistic testing — staging mirrors prod (catch environment-specific issues)
✓ Controlled releases — promote verified code through stages
→ Each environment should be as consistent as possible (config via env vars, IaC).
```

## Hvorfor det betyder noget

At forstå deployment-miljøer er værdifuldt, fordi praksis med at promovere kode gennem flere miljøer er fundamental for sikker softwarelevering, så det er praktisk og brugbar viden.

De typiske miljøer — **udvikling** (hvor udvikler bygger og eksperimenterer, ustabil og ændres hyppigt), **staging** (et **produktionslignende** miljø til endelig test, QA og verifikation) og **produktion** (det live-miljø, der betjener rigtige brugere, hvor stabilitet er kritisk) — tjener hver sit formål i processen fra kode til brugere.

At forstå **promovering af kode gennem miljøer** (kode flyder dev → staging → produktion, hvor man får øget tillid på hver etape, og hvert miljø fungerer som en port, der opfanger problemer før næste etape, og CI/CD-pipelines automatiserer denne promovering) er nøglepraksis.

At forstå **hvorfor flere miljøer betyder noget** er vigtig: de **opfanger problemer før produktion** (test i staging snarere end på rigtige brugere — beskytter live-oplevelsen), giver **isolation** (eksperimentering og fejl i dev uden at påvirke produktion), muliggør **realistisk test** (staging afspejler produktion for at opfange miljø-specifikke problemer, der ikke ville dukke op i dev) og understøtter **kontrollerede udgivelser** (promovering af verificeret kode gennem etaper).

Princippet om at **staging skal meget tæt afspejle produktion** (så test der er realistisk og opfanger prod-specifikke problemer) og at miljøer skal være konsistente (konfiguration via miljøvariabler og Infrastructure as Code) afspejler god praksis.

Da sikker softwarelevering afhænger af test og verifikation af kode, før den når til rigtige brugere, og da multi-miljø-modellen (dev til at bygge, staging til prod-lignende verifikation, produktion til live) med kontrolleret promovering er standardpraksis for dette, er forståelse af deployment-miljøer værdifuld, praktisk-relevant viden for softwarelevering — en fundamental praksis, der beskytter produktion-brugere ved at opfange problemer i tidligere miljøer og kernekompetence for, hvordan software sikkert udvikler sig fra udvikling til live-brug.