CI/CD
Also known as: CI/CD pipeline, continuous integration and continuous delivery, continuous integration and continuous deployment, CICD
CI/CD stands for continuous integration and continuous delivery (or deployment).
Continuous integration automatically builds and tests every code change as developers merge it. Continuous delivery keeps that code always ready to release, and continuous deployment goes further, releasing every passing change automatically. While CI/CD is now standard, many 'pipelines' are just slow scripts; the real goal is fast, trustworthy feedback on every change.
CI/CD, explained at three levels
At home
Imagine a bakery where every new batch is automatically checked for taste and quality before reaching the shelf. CI/CD does that for software: every change is checked automatically, and good changes go out to users quickly.
At work
CI/CD lets teams release updates often and safely. Automated tests catch mistakes early, and automated deployment removes error-prone manual steps.
At home
A CI/CD 'pipeline' is a series of automatic steps: build the code, run tests, check security, then deploy to a test environment and finally to production. If any step fails, the pipeline stops and the developer is notified.
At work
Continuous delivery means every passing build could be released with a button press, often with a human approval. Continuous deployment releases automatically. Pipelines commonly include unit and integration tests, static analysis, dependency scanning, artifact signing, and progressive rollouts.
At home
A pipeline is only as good as its tests. Flaky tests, which pass or fail randomly, teach developers to ignore failures. In my opinion, fixing flaky tests is one of the highest-value jobs in any software team, even though nobody gets promoted for it.
At work
Pipelines are a supply chain target: they hold secrets and produce what runs in production. Use short-lived credentials (OIDC instead of stored keys), pinned third-party actions, isolated runners, and signed artifacts with provenance (for example, following SLSA). Track pipeline duration and failure causes, since slow feedback quietly undermines the whole practice.
Real-world examples
At home
Fatima maintains a small open-source library. She added a GitHub Actions workflow that runs tests on every pull request. Contributors now get feedback within minutes, and she no longer tests their changes by hand.
At work
Sophie is a QA lead at a Toronto health software company that released quarterly after weeks of manual testing. Building a CI/CD pipeline with automated tests let them release every two weeks, with fewer defects reaching clinics.
How it compares
| feature | Continuous integration | Continuous delivery | Continuous deployment |
|---|---|---|---|
| What's automated | Build and test on every merge | Everything up to a release-ready build | Release to production too |
| Human approval | Not applicable | Usually before release | None |
| Release frequency | Not applicable | On demand | Every passing change |
| Test confidence needed | Moderate | High | Very high |
Each step automates more, and demands more trust in your tests.
For analysts
A CI/CD pipeline is also security infrastructure, since it can push code to production. I'd review who can change the pipeline and what secrets it holds, not just how fast it runs.
History & origin
Grady Booch used the term 'continuous integration' in 1991, and Kent Beck's Extreme Programming made it a core practice in the late 1990s. CruiseControl, released in 2001, was one of the first CI servers, followed by Hudson in 2005, which was forked as Jenkins in 2011. Jez Humble and David Farley's 2010 book Continuous Delivery defined the delivery half. Hosted services such as Travis CI, CircleCI, GitLab CI, and GitHub Actions (generally available in 2019) put pipelines next to the code. In my view, CI/CD's greatest success is that it made 'release day' disappear for many teams, replacing a quarterly ordeal with a routine non-event.