People throw "CI/CD" and "DevOps" around as if they were one thing. They are related, and each one builds on the one before it, but they are not synonyms. Here is what each actually means.

Continuous Integration#

Continuous Integration is a team practice: every member merges their work to the mainline frequently — at least once a day, ideally more — and the team keeps the build green at all times. The goal is to catch integration problems while they are small, instead of letting branches drift for weeks and then colliding in a painful merge.

CI goes hand in hand with trunk-based development. If everyone is integrating to the trunk daily, there is no room for long-lived feature branches to diverge, and "it works on my branch" stops being a thing. A red build is treated as a stop-the-line event, because a broken mainline blocks the whole team.

Continuous Delivery#

Continuous Delivery is about working in short cycles so that the software is always in a releasable state. At any moment you could ship what is on the mainline, because it is tested, built, and ready.

The key word is could. With continuous delivery, the actual push to production is a deliberate, manual decision. A human decides when to release — perhaps to line up with a marketing date, a support window, or a business sign-off — but the technical readiness is never the bottleneck. The pipeline has already done the work; someone just has to press the button.

Continuous Deployment#

Continuous Deployment goes one step further: every change that passes the automated pipeline is deployed to production automatically, with no human gate. Commit, the pipeline runs, the tests pass, and the change is live — nobody pressed a button.

This is where the academic distinction between delivery and deployment lives, and it is exactly this: manual versus automated release. Continuous delivery keeps you always ready and lets a human choose the moment; continuous deployment removes the human from that moment entirely.

Crucially, continuous deployment requires continuous delivery as its foundation. You cannot safely automate the release of every change unless every change is already always in a releasable state. Delivery is the prerequisite; deployment is what you can do once you trust it.

DevOps#

DevOps is broader, and it is cultural before it is technical. It is about collaboration across the boundaries that traditionally separated people — development, operations, QA, and management — so that the group shares responsibility for getting working software to users and keeping it running. Alongside that culture, it involves automating the delivery process end to end.

Continuous delivery feeds into DevOps, and DevOps is partly a product of it: you cannot have the tight, shared, automated flow DevOps aims for without the always-releasable discipline that continuous delivery provides. But DevOps is the wider circle. It includes the org structure, the on-call culture, the shared ownership of production, and the tooling — not just the release mechanics.

How they stack up#

Read them as a ladder:

• Continuous Integration — merge to mainline often, keep the build green.
• Continuous Delivery — stay always releasable; a human chooses when to ship.
• Continuous Deployment — every passing change ships automatically; built on top of delivery.
• DevOps — the broader culture and end-to-end automation that the above feed into.

They are related and they reinforce each other, but each describes something distinct. Using the right word for the right idea makes conversations about your pipeline a great deal clearer.