Skip to content
atlas

CI/CD

Also known as: continuous integration and continuous delivery, continuous deployment

Merging, testing and releasing small software changes automatically and often, instead of in rare, large batches.

Draft - this entry has not been reviewed yet.

Formal

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.

In plain English

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.

In practice

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.

Why it matters

Small, frequent, automatically checked changes are easier to review and to undo, and they let security fixes reach production in hours instead of weeks.

How to put it into practice

The usual steps, in order. Adapt them to your organisation.

  1. 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.
  2. Protect the main branch so every change needs a pull request, at least one review and passing status checks, and block force-pushes.
  3. 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.
  4. Produce one immutable, versioned artefact per commit, generate an SBOM for it, sign it and store it in the registry.
  5. 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.
  6. 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.
  7. Release gradually with canary or blue-green deployments, and roll back automatically when health checks or the error budget are breached.
  8. 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.

Common pitfalls

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

Good guides

Technical deep dive

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.

What to learn first

Everything this builds on, foundations first.

  1. Version control
  2. →CI/CD

Relationships

Consists of
Pipeline
Unlocks
DevSecOps

Sources & further reading

Standards & official texts

Reference works

Where this data comes from

This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.

See the review queueSuggest a correction on GitHubThis term as JSON

Check yourself

Loading…

Atlas is in beta.