{"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://atlas.maintz.dev/)"},"id":"platform/ci-cd","url":{"en":"https://atlas.maintz.dev/en/terms/platform/ci-cd/","da":"https://atlas.maintz.dev/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."},"howTo":{"steps":{"en":["Keep each service's code, pipeline definition and infrastructure files in one version-controlled repository, and agree as a team that everyone merges small changes to the main branch at least once a day.","Protect the main branch so every change needs a pull request, at least one review and passing status checks, and block force-pushes.","Build a pipeline that runs on every change - build, unit tests and security checks (SAST, SCA, secrets and IaC scanning) - and keep the fast feedback loop to about ten minutes.","Produce one immutable, versioned artefact per commit, generate an SBOM for it, sign it and store it in the registry.","Deploy that same artefact to test, staging and production, with a manual approval before production if you practise continuous delivery, or automatic release if you practise continuous deployment.","Give the pipeline short-lived OIDC-federated cloud credentials instead of stored keys, separate build and deploy permissions, and pin third-party actions and plugins to full commit SHAs.","Release gradually with canary or blue-green deployments, and roll back automatically when health checks or the error budget are breached.","Track the four DORA metrics every month (deployment frequency, lead time for changes, change failure rate, time to restore service) and improve the slowest or least stable stage first."],"da":["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.","Beskyt hovedgrenen, så hver ændring kræver en pull request, mindst én gennemgang og grønne statustjek, og bloker force-push.","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.","Lav ét uforanderligt, versioneret artefakt pr. commit, generér en SBOM til det, signér det, og læg det i registryet.","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.","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.","Frigiv gradvist med canary- eller blue-green-udrulninger, og rul automatisk tilbage, når helbredstjek eller fejlbudgettet overskrides.","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."]},"pitfalls":{"en":["Calling it CI while developers work for weeks on long-lived branches that are merged just before a release.","Letting untrusted pull-request code run in jobs that can read secrets or deploy, which is poisoned pipeline execution.","Leaving a broken or flaky build red for days, so people learn to ignore failures and bypass the checks.","Turning every scanner on as a blocking gate from day one, so the pipeline becomes slow and noisy and teams work around it."],"da":["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."]},"guides":[{"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","publisher":"NIST","tier":"standard"},{"title":"CI/CD Security Cheat Sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html","publisher":"OWASP","tier":"reference"},{"title":"Continuous Integration (Martin Fowler)","url":"https://martinfowler.com/articles/continuousIntegration.html","publisher":"martinfowler.com","tier":"reference"},{"title":"GitHub Actions - Secure use reference","url":"https://docs.github.com/en/actions/reference/security/secure-use","publisher":"GitHub","tier":"official-doc"}]},"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}