{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/ci-cd","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/ci-cd/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/ci-cd/"},"term":{"en":"CI/CD","da":"CI/CD"},"aka":{"en":["continuous integration and continuous delivery","continuous deployment"],"da":["kontinuerlig integration og levering"]},"domain":["platform"],"cluster":"delivery","layer":"delivery","status":"current","era":2010,"summary":{"en":"Merging, testing and releasing small software changes automatically and often, instead of in rare, large batches.","da":"At samle, teste og frigive små ændringer i software automatisk og ofte i stedet for i få, store leverancer."},"body":{"formal":{"en":"Continuous integration merges each developer's changes into a shared main branch several times a day and checks them with automatic builds and tests; continuous delivery keeps every passing version ready to release, and continuous deployment releases it without a human step.","da":"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."},"plain":{"en":"Like a bakery that checks and ships each tray as soon as it leaves the oven, rather than baking for a month and discovering on delivery day that the recipe was wrong.","da":"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."},"inPractice":{"en":"A developer at a Danish web shop fixes a fault in the discount code field; within minutes the change is built, tested and scanned, and it is live before lunch instead of waiting for the monthly release.","da":"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."},"whyItMatters":{"en":"Small, frequent, automatically checked changes are easier to review and to undo, and they let security fixes reach production in hours instead of weeks.","da":"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."}},"deepDive":{"en":"The term continuous integration is usually credited to Grady Booch (1991) and was made a core practice of Extreme Programming by Kent Beck in the late 1990s; Martin Fowler's article (2000, revised 2006 and 2024) defined its working rules: a single mainline, every developer integrates at least daily, every integration triggers an automated self-testing build, a broken build is fixed immediately, and the build stays fast (the classic target is ten minutes). Continuous delivery, formalised in Humble and Farley's 2010 book, extends this so that every mainline commit produces a releasable artefact via a deployment pipeline; continuous deployment removes the manual approval so every green commit goes to production. The acronym hides this distinction, and many organisations that say \"CI/CD\" practise CI plus scheduled releases.\n\nIntegration frequency is the essential variable. Long-lived feature branches defer merge conflicts and integration bugs, so CI in the strict sense implies trunk-based development or short-lived branches merged via pull requests, with incomplete work hidden behind feature flags. Merge queues serialise merges so that the main branch is tested in the exact state it will have after each merge. Release safety comes from progressive delivery - canary releases, blue-green deployments and automatic rollback on error-budget or health-check breaches. The DORA research programme measures delivery performance with deployment frequency, lead time for changes, change failure rate and time to restore service, and has consistently found that throughput and stability improve together rather than trading off.\n\nSecurity enters CI/CD in two directions. The pipeline is a control point: SAST, SCA, secrets scanning, IaC scanning, SBOM generation, signing and provenance can be enforced on every change, which NIST SP 800-204D (2024) describes for DevSecOps pipelines. It is also high-value attack surface, because CI systems hold credentials for registries, cloud accounts and production. The OWASP Top 10 CI/CD Security Risks catalogue failures such as insufficient flow control (CICD-SEC-1), poisoned pipeline execution where untrusted pull-request code runs with trusted secrets (CICD-SEC-4), insufficient credential hygiene (CICD-SEC-6) and improper artifact integrity validation (CICD-SEC-9). Real incidents include the 2021 Codecov uploader compromise, which exfiltrated CI environment variables, and the March 2025 compromise of the tj-actions/changed-files GitHub Action (CVE-2025-30066), which dumped secrets into public build logs.\n\nStandard mitigations are branch protection with required reviews and status checks, short-lived OIDC-federated cloud credentials instead of stored keys, pinning third-party actions to full commit SHAs, ephemeral isolated runners, separating build from deploy permissions, and verifying signed artefacts before deployment. CI/CD is the practice; the pipeline is the concrete, versioned automation that implements it.","da":"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.\n\nIntegrationshyppigheden 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.\n\nSikkerhed 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.\n\nStandardmodtræ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."},"edges":[{"type":"requires","to":"platform/version-control","confidence":"high","strength":"normal"},{"type":"part-of","to":"platform/software-supply-chain","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/software-composition-analysis","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/pipeline","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/infrastructure-as-code","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/gitops","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/secrets-management","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/container-registry","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/code-signing","why":{"en":"The pipeline's last step signs each release so the servers can check it came from the pipeline unchanged.","da":"Pipelinens sidste trin signerer hver udgivelse, så serverne kan tjekke, at den kom uændret fra pipelinen."},"confidence":"high","strength":"normal"},{"type":"used-with","to":"ai/coding-agent","why":{"en":"Agents are more and more often started from the pipeline itself, and their output must pass the same automatic build and tests as human code.","da":"Agenter startes i stigende grad fra selve pipelinen, og deres output skal gennem samme automatiske bygning og tests som menneskers kode."},"confidence":"medium","strength":"normal"}],"depth":1,"sources":[{"title":"NIST SP 800-204D - Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines","url":"https://csrc.nist.gov/pubs/sp/800/204/d/final","tier":"standard","publisher":"NIST"},{"title":"Continuous Integration (Martin Fowler)","url":"https://martinfowler.com/articles/continuousIntegration.html","tier":"reference"},{"title":"OWASP Top 10 CI/CD Security Risks","url":"https://github.com/OWASP/www-project-top-10-ci-cd-security-risks","tier":"reference","publisher":"OWASP Foundation"}],"draft":true}