Hvad er artefaktadministration i CI/CD?

Question

Accepted Answer

**Artefakter** er output'ene fra build-processen (kompilerede binærer, pakker, Docker-images) som bliver deployed. **Artefaktadministration** — lagring, versionering og promovering af disse artefakter gennem et register/repository — er vigtig for pålidelige, sporbare deployments.

## Hvad artefakter er

```text
The BUILD produces ARTIFACTS — the deployable outputs:
  → Docker IMAGES, compiled binaries, JARs/WARs, npm packages, zip bundles, etc.
→ These are what actually get DEPLOYED (not the source code directly).
```

## Artefaktrepositories/registre

```text
Artifacts are stored in REPOSITORIES/REGISTRIES (versioned, central storage):
  → Container registries: Docker Hub, AWS ECR, GitHub/GitLab Container Registry
  → Package repositories: npm registry, Maven, PyPI, Artifactory, Nexus
→ The pipeline BUILDS an artifact, PUSHES it to the registry, and DEPLOYS from there.
```

## Nøgleprincippet: build én gang, deploy overalt

```text
Build the artifact ONCE, then promote the SAME artifact through environments:
  build → artifact v1.2.3 → deploy to STAGING → (tested) → deploy SAME v1.2.3 to PROD
  ✓ what you TESTED in staging is EXACTLY what you deploy to production (no rebuild)
  ✗ rebuilding per environment risks differences (different deps, build env) → bugs
→ Versioned, immutable artifacts ensure consistency and traceability.
```

## Fordele og praksis

```text
✓ VERSIONING — each artifact tagged with a version → know exactly what's deployed
✓ TRACEABILITY — trace a deployed artifact back to its commit/build
✓ ROLLBACK — redeploy a previous artifact version easily
✓ IMMUTABILITY — artifacts don't change once built (consistent, reproducible)
✓ Retention/cleanup policies; scan artifacts for vulnerabilities
```

## Hvorfor det betyder noget

Forståelse af artefaktadministration er værdifuld, fordi **artefakter er det, der faktisk bliver deployed**, og styring af dem godt er vigtig for pålidelige, sporbare, konsistente deployments, så det er nyttig CI/CD-viden. **Artefakter** (build'ets deployerbare output'er — Docker-images, binærer, pakker) er det, der bliver deployed (ikke kildekode direkte), og lagring af dem i **versionerede registre/repositories** (container-registre, pakke-repositories) er, hvordan pipeline'en administrerer dem: bygge et artefakt, push'e det til registeret, og deploye derfra.

**Nøgleprincippet — build én gang, deploy overalt** — er særligt vigtig: bygge artefaktet **én gang** og promovere det **samme artefakt** gennem miljøer (staging og derefter produktion) sikrer, at **hvad du testede er præcis det, du deployer** (ingen per-miljø genopbygninger, der kunne introducere forskelle fra varierende afhængigheder eller build-miljøer, der forårsager fejl) — en grundlæggende praksis for pålidelige, konsistente deployments, der forhindrer "det fungerede i staging"-klassen af problemer forårsaget af genopbygning.

Forståelse af **fordelene** — **versionering** (vide præcist, hvad der er deployed), **sporbarhed** (spore et deployed artefakt tilbage til dets commit og build, værdifuld til fejlfinding og revision), **let rollback** (redeploy af en tidligere artefaktversion), og **immutabilitet** (artefakter ændres ikke, når de er bygget, hvilket sikrer reproducerbarhed), samt praksis som sårbarhedsscanninger — afspejler, hvordan ordentlig artefaktadministration understøtter pålidelig drift.

Da artefakter er de faktiske deployede enheder, og styring af dem godt (versionering, build-én-gang-deploy-overalt-princippet, sporbarhed, immutabilitet) er vigtig for konsistente, sporbare, pålidelige deployments, og da forståelse af artefakter, registre og især build-én-gang-princippet er værdifuldt for fornuftig delivery, er forståelse af artefaktadministration værdifuld, praktisk relevant CI/CD-viden — en vigtig del af pålidelig delivery, der sikrer konsistens mellem det, der testes og deployes, muliggør sporbarhed og rollback, og afspejler modne deployment-praksis.