Gå til indhold
atlas

CI/CD

Også kendt som: kontinuerlig integration og levering

At samle, teste og frigive små ændringer i software automatisk og ofte i stedet for i få, store leverancer.

Kladde - dette opslag er endnu ikke gennemgået.

Formelt

Kontinuerlig integration fletter hver udviklers ændringer ind i en fælles hovedgren flere gange om dagen og kontrollerer dem med automatiske builds og tests; ved kontinuerlig levering er hver godkendt version klar til frigivelse, og ved kontinuerlig udrulning sættes den i drift uden et menneskeligt trin.

Forklaret enkelt

Som et bageri, der tjekker og sender hver plade ud, så snart den kommer ud af ovnen, i stedet for at bage i en måned og først på leveringsdagen opdage, at opskriften var forkert.

I praksis

En udvikler i en dansk webshop retter en fejl i feltet til rabatkoder; få minutter senere er ændringen bygget, testet og scannet, og den er i drift før frokost i stedet for at vente på den månedlige frigivelse.

Hvorfor det betyder noget

Små, hyppige og automatisk kontrollerede ændringer er lettere at gennemgå og at rulle tilbage, og de lader sikkerhedsrettelser nå driften på timer i stedet for uger.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

  1. Hold hver tjenestes kode, pipelinedefinition og infrastrukturfiler i ét versionsstyret repository, og aftal i teamet, at alle fletter små ændringer ind i hovedgrenen mindst én gang om dagen.
  2. Beskyt hovedgrenen, så hver ændring kræver en pull request, mindst én gennemgang og grønne statustjek, og bloker force-push.
  3. Byg en pipeline, der kører ved hver ændring - build, enhedstests og sikkerhedstjek (SAST, SCA, scanning for hemmeligheder og IaC-scanning) - og hold den hurtige feedback på omkring ti minutter.
  4. Lav ét uforanderligt, versioneret artefakt pr. commit, generér en SBOM til det, signér det, og læg det i registryet.
  5. Rul det samme artefakt ud i test, staging og produktion, med manuel godkendelse før produktion, hvis I praktiserer kontinuerlig levering, eller automatisk frigivelse, hvis I praktiserer kontinuerlig udrulning.
  6. Giv pipelinen kortlivede cloud-legitimationsoplysninger via OIDC-føderering i stedet for gemte nøgler, adskil rettigheder til build og udrulning, og lås tredjeparts-actions og plugins til fulde commit-SHA'er.
  7. Frigiv gradvist med canary- eller blue-green-udrulninger, og rul automatisk tilbage, når helbredstjek eller fejlbudgettet overskrides.
  8. Følg de fire DORA-målinger hver måned (udrulningsfrekvens, gennemløbstid for ændringer, fejlrate for ændringer og tid til genopretning), og forbedr det langsomste eller mest ustabile trin først.

Typiske faldgruber

  • At kalde det CI, mens udviklerne arbejder i ugevis på langlivede grene, der først flettes ind lige før en frigivelse.
  • At lade upålidelig kode fra pull requests køre i jobs, der kan læse hemmeligheder eller rulle ud, hvilket er poisoned pipeline execution.
  • At lade et brudt eller ustabilt build stå rødt i dagevis, så folk vænner sig til at ignorere fejl og omgå tjekkene.
  • At slå alle scannere til som blokerende fra første dag, så pipelinen bliver langsom og støjende, og teamene finder veje uden om den.

Gode vejledninger

Teknisk uddybning

Begrebet kontinuerlig integration tilskrives normalt Grady Booch (1991) og blev gjort til en kernepraksis i Extreme Programming af Kent Beck i slutningen af 1990'erne; Martin Fowlers artikel (2000, revideret 2006 og 2024) fastlagde spillereglerne: én fælles hovedlinje, hver udvikler integrerer mindst dagligt, hver integration udløser et automatisk, selvtestende build, et brudt build rettes med det samme, og buildet holdes hurtigt (det klassiske mål er ti minutter). Kontinuerlig levering, formaliseret i Humble og Farleys bog fra 2010, udvider det, så hvert commit på hovedlinjen giver et frigivelsesklart artefakt via en udrulningspipeline; kontinuerlig udrulning fjerner den manuelle godkendelse, så hvert grønt commit går i drift. Forkortelsen skjuler denne forskel, og mange organisationer, der siger "CI/CD", praktiserer CI plus planlagte frigivelser.

Integrationshyppigheden er den afgørende variabel. Langlivede feature-grene udskyder flettekonflikter og integrationsfejl, så CI i streng forstand forudsætter trunk-based development eller kortlivede grene, der flettes via pull requests, med ufærdigt arbejde skjult bag feature flags. Merge queues serialiserer fletninger, så hovedgrenen testes i præcis den tilstand, den får efter hver fletning. Sikre frigivelser opnås med progressiv levering - canary-udgivelser, blue-green-udrulninger og automatisk tilbagerulning, når fejlbudget eller helbredstjek overskrides. DORA-forskningsprogrammet måler leveringsevne med udrulningsfrekvens, gennemløbstid for ændringer, fejlrate for ændringer og tid til genopretning og har gang på gang fundet, at hastighed og stabilitet forbedres sammen i stedet for at konkurrere.

Sikkerhed kommer ind i CI/CD fra to sider. Pipelinen er et kontrolpunkt: SAST, SCA, scanning for hemmeligheder, IaC-scanning, SBOM-generering, signering og provenance kan håndhæves ved hver ændring, som NIST SP 800-204D (2024) beskriver for DevSecOps-pipelines. Den er også en værdifuld angrebsflade, fordi CI-systemer har legitimationsoplysninger til registries, cloudkonti og produktion. OWASP Top 10 CI/CD Security Risks katalogiserer fejl som utilstrækkelig flowkontrol (CICD-SEC-1), poisoned pipeline execution, hvor upålidelig kode fra en pull request kører med betroede hemmeligheder (CICD-SEC-4), mangelfuld hygiejne omkring legitimationsoplysninger (CICD-SEC-6) og utilstrækkelig validering af artefakters integritet (CICD-SEC-9). Virkelige hændelser omfatter kompromitteringen af Codecovs uploader i 2021, der lækkede miljøvariabler fra CI, og kompromitteringen af GitHub Action'en tj-actions/changed-files i marts 2025 (CVE-2025-30066), der dumpede hemmeligheder i offentlige build-logs.

Standardmodtræk er grenbeskyttelse med krævede gennemgange og statustjek, kortlivede cloud-legitimationsoplysninger via OIDC-føderering i stedet for gemte nøgler, fastlåsning af tredjeparts-actions til fulde commit-SHA'er, flygtige og isolerede runners, adskillelse af rettigheder til build og udrulning samt verifikation af signerede artefakter før udrulning. CI/CD er praksissen; pipelinen er den konkrete, versionsstyrede automatisering, der implementerer den.

Hvad du bør lære først

Alt det, dette bygger på - grundlaget først.

  1. Versionsstyring
  2. →CI/CD

Relationer

Består af
Pipeline
Forudsætter
Versionsstyring
Åbner for
DevSecOps

Kilder og videre læsning

Standarder og officielle tekster

Opslagsværker

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON

Test dig selv

Indlæser…

Atlas er i beta.