CI/CD

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.