What Is CI/CD, Really

Ask ten engineers what CI/CD means and you'll get a strange spread of answers. Some say it's the thing that runs your tests. Some say it's how code gets to production. Some just point at a green checkmark on a pull request and shrug. They're all half right, which is the problem. CI/CD is not one idea. It's three, crammed into four letters, and the confusion is baked into the acronym itself.

Here's the honest breakdown. CI/CD stands for continuous integration plus continuous delivery, or continuous deployment, and those last two are different things that share an abbreviation. Continuous integration is about merging and testing code constantly. Continuous delivery is about keeping that code always ready to ship. Continuous deployment is about actually shipping it, automatically, with no human in the loop. Getting the distinction right is the difference between a team that ships with confidence and one that has a pipeline that runs tests and still deploys by hand on Fridays.

The three things hiding in two letters

Let's untangle the acronym, because almost every muddled conversation about CI/CD traces back to people using the same words for different things.

Continuous integration is the oldest and least controversial piece. The idea, championed by Martin Fowler and the extreme programming crowd back in the early 2000s, is that developers merge their work into a shared main branch often, at least daily, and every merge automatically triggers a build and a test run.^[1] The enemy here is the long-lived branch. When you sit on your own copy of the code for three weeks, then try to merge it back, you get a painful pile of conflicts and surprises. Integrate constantly and each merge is tiny, so the pain never accumulates.

Continuous delivery extends that. Now it's not enough that the code merges and passes tests. Every build that passes must be in a state you could ship to production right now, on demand, with a single deliberate action.^[2] The code is always releasable. A human still decides when to actually pull the trigger, but the release itself is a button, not a two-day ritual.

Continuous deployment takes the human out. Every change that passes the full automated pipeline goes to production on its own, no approval, no button.^[2] This is the part teams find scary, and reasonably so. It only works if your tests are genuinely trustworthy, because they are now the last line of defense between a commit and your users.

The distinction everyone gets wrong

I want to sit on this because it matters more than any diagram. Continuous delivery and continuous deployment both shorten to “CD.” They are not the same practice, and swapping them changes what you're actually committing to.

Continuous delivery says: we can ship at any moment, and we choose when. That's a great fit for a bank, a medical device, anything where a release needs a human signoff or a scheduled window. Continuous deployment says: we ship whatever passes, whenever it passes, and we trust the pipeline to catch what a human would. That's how companies push to production dozens or hundreds of times a day.

Most teams that say they do “continuous deployment” are actually doing continuous delivery with a fast approval step, and that's completely fine. The failure mode isn't picking the wrong one. It's not knowing which one you have, and then being surprised when a change you didn't review goes live, or when the “automated” pipeline stalls for two days waiting on a manager who's on vacation.

Why it exists: small batches beat big ones

Strip away the tooling and CI/CD is really one bet: small, frequent changes are safer than large, rare ones. That sounds backwards to a lot of people. More releases means more chances to break things, right? In practice, the opposite holds, and it's the single most important thing to understand about why any of this exists.

Think about debugging. You merge a ten-line change, a test goes red, and you know within minutes that the problem is in those ten lines. Now compare that to a quarterly release where three months of work from twelve people lands at once. Something breaks in production. Where is it? It could be anywhere in ten thousand lines, tangled up with everyone else's changes. The failure isn't bigger, but finding it is exponentially harder, because the search space exploded.

Fast feedback is the other half of it. The value of a test result decays with time. Learning your change broke something ninety seconds after you pushed it, while the context is still in your head, is worth ten times more than learning it three weeks later in a staging environment you've since forgotten about. CI/CD is an engine for shrinking that gap between doing a thing and finding out whether the thing worked.

This is also why CI/CD pairs so naturally with a clean git history. If you're integrating daily, how you combine branches matters, and the tradeoffs there are the subject of our git rebase vs merge breakdown. Small, frequent merges are exactly the situation where those choices start to bite.

The pipeline: build, test, deploy

A CI/CD pipeline is just an ordered series of stages that a change has to pass through. The classic three are build, test, and deploy, and while real pipelines add more, that spine is universal.

Build compiles the code and packages it into a deployable artifact, often a container image. Test runs checks against that artifact, unit tests first, then integration tests, sometimes end-to-end tests that spin up a real environment. Deploy pushes the validated artifact out, usually to a staging environment first and then to production. GitLab's docs describe this same shape, with pipelines built from stages that run in sequence and jobs that run within them.^[3]

The one design rule that matters most here is fail fast. Order your stages cheapest and quickest first. A build takes seconds, so run it first. If the code doesn't even compile, there's no point spending twenty minutes on a slow integration suite. Catch the dumb failure early, free up the runner, and give the developer feedback while they're still paying attention. A pipeline that runs its slowest checks before its fastest ones is wasting both machine time and human attention.

The reason the artifact tends to be a container image is worth a beat. A container packages the code and its entire environment together, so the exact thing you tested is the exact thing you deploy. No “works on my machine.” If you're fuzzy on why that isolation matters, our Docker vs virtual machines piece covers the mechanics. For CI/CD, the point is simple: a reproducible artifact is what makes the pipeline's promise honest.

The tools are the easy part

GitHub Actions, GitLab CI/CD, Jenkins, CircleCI. These are the automation engines, and honestly they're interchangeable enough that the choice rarely makes or breaks a team. GitHub Actions runs workflows defined in YAML files inside your repo, triggered by events like a push or a pull request, and spins up runners to do the work.^[4] GitLab bakes the same idea into a single application alongside the repo. AWS offers CodePipeline and CodeBuild for teams already living in that ecosystem.^[5] They all do the same fundamental job: watch for a change, run your stages, report back.

The trap is thinking that installing one of these means you “have CI/CD.” You don't. You have a tool that can run a pipeline. Whether it delivers the actual benefit depends on things the tool can't give you: a test suite thorough enough to trust, a team habit of merging small and often, and the organizational nerve to actually ship on green instead of batching up for a big scary release.

Where CI/CD gets genuinely hard is at organizational scale, and that's a structural question as much as a tooling one. How you lay out your repositories shapes how your pipelines behave, and that tradeoff is the subject of our monorepo vs polyrepo piece. A giant shared pipeline and a swarm of tiny independent ones are very different animals, and the repo structure decides which one you're running.

What I'd do

The way I think about it, CI/CD is one of those things where the culture is ninety percent of the work and the tooling is ten. Any team can wire up GitHub Actions in an afternoon. Almost none of the value shows up until people actually change how they work: merging to main every day instead of hoarding branches, writing tests they trust instead of tests they tolerate, and shipping small pieces continuously instead of stockpiling changes for a release that everyone dreads.

So if I were setting this up from scratch, I'd start with continuous integration and get it genuinely solid before reaching for anything fancier. Merge often, test everything, keep the build green, make the feedback loop fast. Once that's a real habit and the tests are trustworthy, move to continuous delivery, so you can ship on demand with one click. Continuous deployment, the fully automated version, is a destination you earn by proving your tests catch what matters, not a starting point you configure on day one. And whatever you do, be clear about which of the three you actually have. Confidence in shipping comes from knowing exactly what the pipeline decides and what you still decide yourself. That clarity is the real product here. The green checkmark is just the receipt.