What is CI/CD?
Ask a vendor how a change reaches production. If the answer is a person copying files by hand, you have your answer about the rest of the build too.
CI/CD
continuous integrationcontinuous delivery
CI/CD pairs continuous integration with continuous delivery. Every code change gets tested the moment it's merged, and the codebase stays in a state that can ship at any time.
The two halves solve different problems. Integration, the first half, answers 'does this change break anything?' A developer pushes code. A pipeline runs the test suite against it within minutes, before anyone reviews it by eye.
Delivery, the second half, answers a different question: can we ship this right now? A change that passes the tests gets packaged and staged automatically. It waits, ready for a human to approve. Deployment skips that approval and pushes straight to production once checks pass.
Most teams that say CI/CD run continuous delivery, not full continuous deployment. A person still clicks the button. What's automated is everything before that click: the build, the tests, the packaging, and the environment the change lands in.
It's the question that exposes a demo-grade team
A working demo and a system you can safely change for five years look identical on a screen share. The difference shows up the moment someone asks how a fix reaches production. Google's DORA research (State of DevOps, 2024) tracks deployment frequency and change failure rate across thousands of teams. Both correlate with whether a pipeline exists at all.
Without CI/CD, every release is a manual event. Someone remembers which files to copy, runs tests by hand if they run them at all, and hopes staging matched production closely enough. Each release is a new chance to skip a step. With CI/CD, the steps are code, and skipping one means the pipeline fails.
This is why we build a pipeline on day one of every engagement rather than after the first incident. A system with no pipeline is missing more than a convenience. Nobody has verified that the last ten changes still work together.
- CommitA developer merges a change to the main branch.
- BuildThe pipeline compiles it and installs dependencies fresh.
- TestThe automated suite runs. Any failure stops the pipeline here.
- StageA passed build deploys to an environment that mirrors production.
- ReleaseApproved automatically or by one click. Rollback is the same pipeline in reverse.
Every step is code. A human decides whether to release, not whether the change was tested.
Common questions
01Is CI/CD the same as DevOps?
No. DevOps is a broader set of practices covering how development and operations teams work together, including culture and incident response. CI/CD is one concrete piece of that: the automated pipeline from commit to release. You can run CI/CD without adopting every DevOps practice, and plenty of teams do.
02What's the difference between continuous delivery and continuous deployment?
Continuous delivery automates everything up to a release that's ready to ship, then waits for a person to approve it. Deployment goes further and removes that approval step, releasing automatically once the checks pass. Most production teams use continuous delivery, because some changes still warrant a human decision on timing.
03Do AI-assisted builds still need CI/CD?
More than before, not less. Code an AI coding assistant writes quickly still has to pass the same tests as code written by hand. A pipeline checks that automatically instead of on trust. Skip CI/CD to move faster with AI tools, and you ship faster and break things faster in the same proportion.
04How is CI/CD different from regression testing?
Regression testing is one of the checks a CI/CD pipeline runs, not the whole pipeline. CI/CD also covers the build, the packaging, the deployment to staging, and the release itself. A pipeline without regression tests still runs; it just doesn't catch the class of bug those tests exist for.
Related terms
- Regression evals →The AI-era version of the same idea: a check that runs automatically before a model change ships.
- Custom software development →Where the pipeline gets built, on day one of the engagement rather than after the first incident.
- Vibe-coded prototype vs. production build →A missing or cosmetic pipeline is one of the clearest signals a build never left prototype stage.
