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
Think of a bakery where every batch passes automatic checks for weight, temperature, and taste before going on the shelf, and good batches are delivered to stores right away. CI/CD does that for software. Every change a developer makes is automatically built and tested, and changes that pass are packaged and sent toward users quickly, without anyone doing those steps by hand.
At work
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 the result always ready to release; continuous deployment releases every passing change automatically. Businesses care because updates reach customers faster and more safely, with automated tests catching mistakes early and fewer error-prone manual release steps.
At home
A CI/CD pipeline is a chain of automatic steps triggered when code changes. First the code is built into a runnable package. Then tests run, from small unit tests checking single functions to broader tests checking parts together. Security scans look for known flaws. If everything passes, the package is deployed to a test environment, then to production. Any failure stops the chain and alerts the developer.
At work
At work, pipelines are defined as code, in files such as GitHub Actions workflows or GitLab CI configuration stored with the application, and runners execute the jobs. A typical pipeline builds once, producing a versioned artifact like a container image, then promotes that same artifact through environments. Stages include unit and integration tests, static analysis, dependency scanning, and signing. Continuous delivery adds a human approval before production; continuous deployment removes it.
At home
A pipeline is only as trustworthy as its tests. Flaky tests, which pass or fail randomly because of timing or shared state, teach developers to rerun failures until they pass, and soon real failures get ignored too. Slow pipelines do similar damage by delaying feedback. 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 prime supply chain target because they hold secrets and produce what runs in production, as the SolarWinds and Codecov breaches showed. Use short-lived credentials through OIDC federation instead of stored keys, pin third-party actions to commit hashes, isolate runners, and sign artifacts with provenance following the SLSA framework, using tools such as Sigstore. Track pipeline duration and failure causes, since slow, unreliable 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.