CI/CD

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.

Integration 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.

Security 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.

Standard 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.