CI/CD
Also known as: continuous integration, continuous deployment, continuous delivery
An automated pipeline that builds, tests, and ships code on every change — so the path from "git push" to "in production" is short, repeatable, and safe.
- Primary domain
- Software Engineering & Notation
- Sub-category
- IDEs & Software Configuration Management
In simple terms
CI/CD stands for Continuous Integration and Continuous Delivery (or Deployment). It’s the practice — and the toolchain — that runs your tests on every commit and automatically packages and ships the code if those tests pass. The goal is to make releases boring: small, frequent, and reversible.
More detail
Continuous Integration (CI) focuses on the path from commit to merged:
- Every push triggers a pipeline: install dependencies, lint, type-check, build, run tests, scan for vulnerabilities.
- Branches merge to
mainonly when the pipeline is green. - Failures are loud and quick to fix while the change is small.
Continuous Delivery extends the pipeline: any green main is deployable on demand. Continuous Deployment removes even the manual click: every green main goes to production automatically.
A typical pipeline:
push → lint → build → unit tests → integration tests → security scan
→ docker image → deploy to staging → smoke tests → manual approval?
→ canary deploy to production → full rollout
Mainstream platforms:
- GitHub Actions, GitLab CI/CD, Bitbucket Pipelines (Git-host-native).
- Buildkite, CircleCI, Jenkins (standalone).
- Argo CD, Flux (GitOps-style continuous deployment to Kubernetes).
Healthy pipelines:
- Run in < 10 minutes for most repos (faster is better).
- Cache aggressively (dependencies, builds, Docker layers).
- Are deterministic: same commit, same result.
- Run on every commit, not just
main.
Why it matters
CI/CD turns “release day” into “every day”. It catches bugs while the diff is small, makes rollback a one-command operation, and lets a team ship many times per day with confidence. The Accelerate / DORA research links high deploy frequency directly to organisational performance.
Real-world examples
-
A typical PR opens, runs ~3 minutes of CI, gets reviewed, gets merged, and is in production within an hour.
-
Large companies (Amazon, Google) deploy thousands of times per day across their services.
-
A canary deploy shifts 5% of traffic to the new version first; if metrics stay healthy, it rolls forward.
-
Spotify deploys to production thousands of times a day; their entire pipeline (build, test, canary, full rollout) is measured in minutes, not hours.
Common misconceptions
- “CI = running tests.” Tests are the core; lint, build, security scan, and packaging are part of it too.
- “Continuous deployment is reckless.” Done with good tests, canary deploys, and observability, it is less risky than infrequent big-bang releases.
Learn next
The release end of the pipe: deployment. The discipline that fills the pipe: testing.
Read this in a learning path
All paths →This topic is part of 3 learning paths. Start in context to keep prev/next and progress tracking.
- Read this in Backend Engineer Starter KitThe minimum set of topics that turns a programmer into someone who can ship and operate a backend service in production. Start here View the whole path
- Read this in Frontend Engineer Starter KitThe topics that take you from "I can write some JavaScript" to "I can ship a real product on the web that respects users". Start here View the whole path
- Read this in Software Engineering PracticesThe discipline behind writing code that teams can maintain, test, and evolve — from version control to deployment pipelines. Start here View the whole path
Relationships
- Requires
- Related
- Next
- Leads to
- Required by
Neighborhood
A visual companion to the relationships above. Click any node to visit that topic.