CI and CD are often bundled together, but they solve different problems. Treating them as a single pipeline hides where responsibility should live.
My take is simple:
- CI should be owned by Development
- CD should be owned by Operations
That’s not about silos. It’s about clear accountability where the risk actually sits.
CI is a Dev responsibility
CI is about producing a correct, repeatable artifact. That’s core development work.
CI includes compiling and packaging code, running tests and static analysis, validating contracts, schemas, and API compatibility, and producing a versioned artifact that can be trusted.
Developers are best placed to own CI because they understand the code and test intent, can fix failures quickly without handoffs, and decide what “good” looks like for the codebase.
If CI is weak, CD can’t make it safe. A clean deployment of a broken build is still broken.
CD is an Ops responsibility
CD is about safely releasing into real environments. That’s operational work.
CD includes environment promotion and change control, configuration and secret management, deployment strategies like blue/green and canary, and monitoring, alerting, and post-deploy verification.
Operations owns CD because they manage runtime risk and customer impact, control production access and compliance, and run incident response when releases go wrong.
CD isn’t just a button that says “deploy”. It’s a set of controls that protect production and the people using it.
Where the boundary should sit
The cleanest line is the artifact.
Development owns everything up to build once. Operations owns everything after deploy many.
That creates an explicit contract — dev delivers a versioned, immutable artifact, and ops promotes that exact artifact across environments.
The handoff isn’t a gate. It’s a handshake.
Why this split works
When ownership aligns with responsibility, things get better on both sides. CI improves because devs can make changes without operational friction. CD improves because ops can harden releases without touching code. Production accountability stays where it belongs, so when something goes wrong there’s no debate about whose problem it is.
In practice, this split also removes the “who broke prod” argument. CI answers “is the build correct?” and CD answers “is the release safe?” Those are different questions, and they deserve different owners.
Shared goals, separate ownership
This doesn’t mean teams stop collaborating. It means collaboration has structure.
The best setups I’ve seen have shared standards for artifact versioning and immutability, joint review of deployment strategies and rollback plans, clear SLAs for CI duration and CD approval windows, and a single source of truth for release history.
Dev and Ops are on the same side. Ownership is just how you make that cooperation reliable.
Conclusion
CI and CD aren’t just stages in a pipeline. They’re different domains of responsibility.
Let devs own CI so the artifact is trustworthy. Let ops own CD so production stays safe. In most teams those lines are blurrier than this — and that’s usually where the problems start.
I’d be interested to hear how your team handles the split, or whether you think the boundary sits somewhere different. Feel free to reach out!
