This article is based on a piece originally published on devops.com. The core concepts have been expanded and clarified for a DevOps engineering audience.
The Terminology Problem
The abbreviation “CD” appears constantly in DevOps conversations, job descriptions, and tool documentation. The problem is that it stands for two related but distinct practices: Continuous Delivery and Continuous Deployment. Engineers new to DevOps frequently assume these are interchangeable. They are not, and conflating them leads to real misunderstandings about pipeline design, release governance, and tooling choices.
Defining Each Practice
Continuous Integration (CI)
Developers merge code changes into a shared repository frequently—often multiple times per day. Each merge triggers an automated build and a baseline set of tests. The output is a verified, deployable artifact: a package, container image, or binary that has passed automated quality gates.
Continuous Delivery
Continuous Delivery extends CI by ensuring that every artifact produced by the build pipeline is in a state where it could be released to production at any time. The key word is could. The decision to actually push a release to production remains a human one, often gated by business, compliance, or marketing considerations. The pipeline guarantees readiness; it does not guarantee release.
Continuous Deployment
Continuous Deployment goes one step further: every artifact that passes all automated gates is automatically pushed to production without manual approval. There is no human in the loop between a successful build and a live release. This demands a high degree of confidence in test coverage, infrastructure-as-code, and monitoring.
| Practice | Artifact Always Releasable? | Release to Production | Human Approval Required? |
|---|---|---|---|
| Continuous Integration | Goal, not guaranteed | Manual | Yes |
| Continuous Delivery | Yes | On demand | Yes |
| Continuous Deployment | Yes | Automatic | No |
Why the Distinction Matters in Practice
Most CI/CD tools produce a new deployable artifact on every code commit. In theory, each of those artifacts is a candidate for production. In practice, organizations deploy far less frequently than they build, because deployment is governed by factors beyond code quality:
- Environment readiness: Test, Staging, and Production environments must be provisioned, configured, and validated before a deployment can succeed.
- Release coordination: Marketing launches, feature flags, and regulatory windows all influence when code actually ships.
- Risk appetite: Not every organization is comfortable with fully automated production releases. Compliance-heavy industries (finance, healthcare) often mandate explicit change-approval processes.
Understanding which “CD” your pipeline implements determines how you design approvals, environment promotion strategies, and rollback procedures.
Deployment Is a Separate Step—and a Separate Discipline
Building a deployable artifact and deploying it are fundamentally different operations. Deployment means placing an artifact into a running environment that has its own network topology, data sources, storage configuration, secrets, and access controls. Setting up and managing that environment is a distinct engineering concern.
Many teams handle environment configuration through shell scripts. Scripts are a legitimate first step—they automate what was previously done by hand—but they carry significant long-term costs:
- Fragility: When a configuration detail changes (a database hostname, a secrets manager endpoint, an AAA server address), the change must be made in every environment-specific script separately. Miss one, and Test no longer mirrors Production.
- No built-in versioning: Scripts are typically forward-looking. Rolling back to a previous deployment state requires manually reversing changes—if backout scripts exist at all.
- Drift: Hand-edited scripts diverge over time, making environment parity difficult to maintain and audit.
Moving Beyond Scripts: Continuous Deployment Tools and ARA
Purpose-built continuous deployment tools and Application Release Automation (ARA) platforms address the weaknesses of script-based deployments. Their core value propositions include:
Shared and Environment-Specific Configuration
Good deployment tools allow you to define a shared deployment model that applies to all environments, with overrides scoped only to what genuinely differs between Test and Production. A database hostname change is made in one place; the tool resolves the correct value per environment at deploy time.
Versioned Deployments and Rollback
Source code has been version-controlled for decades. Deployment state deserves the same treatment. When deployments are versioned, rolling back to a previous known-good state becomes a first-class operation rather than an emergency fire drill. This is critical for scenarios such as:
- A bug fix that introduced a regression worse than the original bug.
- A release found to violate a compliance requirement (e.g., GDPR) after it reaches production.
- A failed A/B test where the variant must be retired quickly.
Version-controlled deployments also enable multi-version deployments—running two releases simultaneously for A/B testing or canary rollouts—and the ability to skip forward or backward to any prior release.
Agentless Targeting
Early deployment automation required agents installed on every target host. Modern tools increasingly support agentless approaches (using SSH, WinRM, or cloud-provider APIs), reducing the operational overhead of maintaining a deployment fleet and making it easier to include ephemeral infrastructure in deployment workflows.
Environment Parity: The Overlooked Requirement
Test, Staging, and Production environments will never be identical—they occupy different network segments, use different data sets, and often run on different infrastructure scales. That is expected. What is not acceptable is allowing the deployment process itself to differ between environments. If Production is deployed by a manual runbook and Test is deployed by an automated tool, your test results are not meaningful. The deployment mechanism must be consistent across all environments, with only environment-specific variables changing.
Choosing the Right Approach for Your Organization
Not every team needs full Continuous Deployment. The right choice depends on:
- Test coverage confidence: Continuous Deployment to production is only viable when automated tests can catch the overwhelming majority of regressions before they ship.
- Regulatory environment: Industries with change-management mandates may require Continuous Delivery with an explicit approval gate rather than fully automated deployment.
- Release cadence: Teams deploying dozens of times per day benefit most from full automation. Teams releasing monthly may find Continuous Delivery sufficient.
- Organizational maturity: Scripts are a valid starting point. Migrating to a proper deployment tool is a worthwhile investment once script maintenance becomes a bottleneck.
Key Takeaways
- Continuous Delivery guarantees that your software is always in a releasable state. It does not mean it is automatically released.
- Continuous Deployment means every successful build goes to production automatically. It requires a high level of automated test confidence and infrastructure maturity.
- Deployment is a separate engineering concern from building. It requires its own tooling, versioning strategy, and environment-parity discipline.
- Script-based deployments are fragile and lack rollback capability. Purpose-built deployment tools or ARA platforms reduce fragility and enable versioned, repeatable releases.
- Agentless deployment tools reduce operational overhead and increase flexibility across diverse infrastructure.
- Whatever tooling you choose, the deployment mechanism must be consistent across all environments—only environment-specific variables should differ.
Closing the gap between Continuous Delivery and Continuous Deployment—the so-called “DevOps last mile”—is one of the highest-leverage improvements a mature engineering organization can make. It reduces release risk, accelerates feedback loops, and removes the fragility inherent in hand-maintained scripts.