Why CI and CD Should Be Treated as Separate Disciplines (Not CI/CD)

For years, teams have bundled continuous integration (CI) and continuous delivery (CD) into a single concept: CI/CD. This shorthand suggests a seamless pipeline, but in practice, it creates confusion and hides the fact that CI and CD solve very different problems.

CI is like the quality control process in a factory, meticulously inspecting and testing every component to ensure it's safe and meets standards before it's ever installed. CD, on the other hand, is the logistics company, using a deliberate strategy to deliver the finished product to the customer, monitoring its journey, and having a plan for a safe return if something goes wrong. Treating them as one often creates unoptimized workflows, blurs the separation of responsibilities, and causes confusion about what is needed when.

To further the argument, here are a few concrete reasons why you should be thinking of them as separate things.

Different Goals

Continuous Integration (CI): Quality and Confidence

• The core question: “Is my change safe enough to merge?”
• Focus areas: CI is about validating that code meets quality, security, and compliance standards before it enters the main branch.
• Practices: automated builds, unit and integration tests, static analysis, vulnerability scanning, dependency checks, artifact signing, and SBOM generation.
• Outcome: A trusted artifact that can be confidently promoted downstream.
• Example: If a developer submits a pull request, the CI ensures, within minutes, that the change compiles, passes tests, doesn’t break dependencies, and is safe to integrate.

Continuous Delivery (CD): Safe and Progressive Rollout

• The core question: “Can we reliably and securely deliver this artifact to its intended consumers—whether people, services, or APIs?”
• Focus areas: CD is about risk management, governance, and customer impact once the artifact is built.
• Practices: environment promotion (dev → staging → prod), canary or blue/green rollouts, feature flag management, compliance gates, audit logging, and rollback procedures.
• Outcome: A reliable and observable release process that delivers changes with minimal disruption.
• Example: A new feature is rolled out gradually to 1% of users, monitored for errors, then expanded to 100% once stability is confirmed.

Different Timelines

CI: Fast, Continuous, and High-Frequency

• Every commit and pull request triggers CI.
• The emphasis is on speed — feedback loops must be short (minutes, not hours) so developers can act immediately.
• Failures should block merges, preventing broken code from entering the mainline.
• Analogy: Like a factory inspection that happens on every single part, every time.
• Example: A developer pushing 10 commits in a day expects CI to validate each one quickly.

CD: Deliberate, Risk-Aware, and Staged

• Rollouts happen at a slower cadence — daily, weekly, or on-demand, depending on risk tolerance.
• Requires coordination across environments, approvals, and sometimes regulatory compliance.
• Monitoring windows may extend hours or days after a release before full rollout.
• Analogy: Like a logistics company moving goods across borders — timing matters, permits matter, and a recall plan must exist.
• Example: A financial services company might run CI on every change but only release production updates weekly due to compliance requirements.

Different Teams

CI Ownership: Developers and Platform Teams

• The goal is to empower developers to move quickly without breaking things.
• Responsibilities include maintaining build systems, test frameworks, and integration signals.
• Platform teams provide standardized CI infrastructure, caching, remote execution, and reusable build rules so every team isn’t reinventing the wheel.
• Example: A platform engineering team runs the CI cluster, but developers own test coverage and fixing broken builds.

CD Ownership: Release Engineering, SRE, Operations, and Product

• The goal is to protect customers and business outcomes during releases.
• Responsibilities include defining rollout strategies, monitoring production, enforcing governance, and triggering rollbacks if needed.
• Product owners may set release cadence; operations teams ensure compliance and reliability.
• Example: SREs own monitoring dashboards and rollback automation, while release managers coordinate staged rollouts across geographies.

Different Abstractions

CI Abstractions: Build, Test, and Validation

• Build pipelines – automated workflows that compile and test code, ensuring every commit produces consistent results
• Dependency management – standardized handling of libraries and packages to avoid version drift and vulnerabilities
• Remote execution and caching – speeds up builds/tests by distributing work and reusing outputs
• Artifact signing and storage – ensures artifacts are tamper-proof, traceable, and available for downstream delivery
• SBOM and compliance checks – generate software bills of materials and validate compliance early in the cycle

CD Abstractions: Release, Risk, and Control

• Environment promotion – moves artifacts through dev, staging, and production with clear validation gates.
• Rollout policies – blue/green, canary, or progressive strategies that reduce blast radius and manage risk.
• Feature flags – decouple deployment from release, enabling safe toggles, experiments, and instant rollbacks.
• Observability and monitoring – built-in health checks and alerts that validate success during rollout.
• Rollback and governance – automated rollback on failures, with compliance and audit controls for accountability

The Danger of One “Pipeline”

Forcing CI and CD into a single YAML or workflow couples these abstractions in ways that make systems rigid and fragile. Build failures block releases unnecessarily, rollout strategies become entangled with developer tests, and ownership gets muddied. This reduces agility and increases operational risk.

Conclusion

• CI ensures every change is safe to merge.
• CD ensures every change is safe to release.

CI and CD are both critical, but treating them as one blurs their purpose and diminishes their impact. To build developer platforms that are secure, scalable, and truly empowering, we must stop hiding behind the shorthand of “CI/CD” and instead invest in CI and CD as distinct, composable disciplines. 

With a clear separation, organizations gain the best of both worlds: developers iterate quickly with confidence, and operations deliver safely with control. Collapsing them into a single concept may sound convenient, but in reality, it creates confusion, slows progress, and makes systems more fragile.