LFCA 84 🐧 Continuous Delivery vs Continuous Deployment - KandZ

The previous chapter covered Continuous Integration — the practice of merging code frequently and verifying it automatically. This chapter covers the two practices that follow: Continuous Delivery and Continuous Deployment. They are often confused because they share the same abbreviation, CD. But they are different practices with different workflows, different risk profiles, and different requirements.

The LFCA exam places CI/CD under DevOps Fundamentals, which carries 12–16% of the total weight. The study plan lists “DevOps Basics” and “Deployment Environments” as core topics. The exam expects you to understand the distinction between the two CD practices and when each is appropriate.

Key point: Continuous Delivery means every change that passes the pipeline is ready for production, but a human decides when to deploy. Continuous Deployment means every change that passes the pipeline is deployed to production automatically, with no human intervention. The difference is the approval gate. Everything else in the pipeline is the same .

Why the distinction matters

The two practices sound similar, and in many ways they are. Both require the same automated pipeline. Both require reliable tests. Both require monitoring and rollback capability. The difference is where the human decision sits.

The risk problem. Continuous Deployment removes the human gate. Every commit that passes the pipeline goes to production. This is only safe if the pipeline is trustworthy. If the tests miss a bug, the bug reaches production. Continuous Delivery keeps the human gate. The human can review the staging deployment, run additional checks, and decide when to release. The human catches what the pipeline misses .

The governance problem. Some industries have regulatory requirements that mandate human approval before production changes. Financial services, healthcare, and government applications often fall into this category. Continuous Deployment is not permitted in these environments. Continuous Delivery provides the automation while preserving the approval step .

The cadence problem. Continuous Deployment is not always faster than Continuous Delivery. A team practicing Continuous Delivery might deploy to production multiple times per day. The difference is not the frequency. It is the decision-making. In Continuous Deployment, the decision is automatic. In Continuous Delivery, the decision is made by a human, but it can still be made quickly.

The culture problem. Continuous Deployment requires a culture of trust. The team must trust the pipeline, the tests, and the monitoring. If the team does not trust the pipeline, they will not use Continuous Deployment. Continuous Delivery is more forgiving. The human gate provides a safety net.

The trade-off. Continuous Deployment provides the fastest feedback loop and the highest deployment frequency. It also carries the most risk if the pipeline is not mature. Continuous Delivery provides the automation without the automatic production deployment. The choice depends on the team’s maturity, the application’s risk profile, and the regulatory environment.

a. Continuous Delivery

Continuous Delivery is the practice of keeping the code always in a deployable state. Every change that passes the CI pipeline is automatically deployed to a staging environment. The staging environment mirrors production as closely as possible. The application is validated in staging. When the validation passes, the artifact is ready for production. A human approves the deployment, and the artifact is promoted to production .

The key characteristics of Continuous Delivery are:

Automated deployment to staging. The staging deployment is automatic. The developer does not need to trigger it. The pipeline deploys to staging after the CI stages pass.

Automated validation in staging. The staging environment runs the acceptance tests, the smoke tests, and any other validation that verifies the application works in a production-like environment.

Manual approval for production. The production deployment requires a human approval. The approval is a governance gate. The approver reviews the staging deployment and the test results. The approval can be a button click, a pull request approval, or a formal change management process.

Production-ready artifact. The artifact that was validated in staging is the same artifact that goes to production. It is not rebuilt. It is not modified. The artifact is immutable .

Rollback capability. The pipeline includes a rollback path. If the production deployment fails, the team can revert to the previous version. The previous version is a known artifact in the registry.

Continuous Delivery is the recommended starting point for most teams. It provides the automation and the speed of Continuous Deployment without the risk of automatic production deployment. The human gate is the safety net that catches the issues the pipeline missed .

b. Continuous Deployment

Continuous Deployment takes the final step. Every change that passes the pipeline is deployed to production automatically. There is no manual approval. The pipeline is the only gate .

The key characteristics of Continuous Deployment are:

No manual approval. The production deployment is automatic. The pipeline decides when to deploy. The developer does not need to click a button.

High deployment frequency. The team deploys multiple times per day. The deployments are small and frequent. The change set is small, which makes debugging easier.

Robust automated testing. The test suite is comprehensive and reliable. The tests must catch the bugs that would otherwise reach production. A flaky test is a blocker.

Advanced monitoring. The production environment is monitored in real time. The monitoring detects anomalies and triggers alerts. The alerts trigger the rollback or the investigation.

Automated rollback. The rollback is automatic. If the monitoring detects a failure, the pipeline reverts to the previous version without human intervention.

Feature flags. New features are deployed behind feature flags. The code is in production, but the feature is not enabled. The team can enable the feature for a subset of users, monitor the results, and expand the rollout gradually .

Continuous Deployment is the goal for teams that have invested in test reliability, monitoring, and rollback automation. It is not the starting point. It is the destination .

c. Choosing Between the Two

The choice between Continuous Delivery and Continuous Deployment depends on several factors.

The risk tolerance. A team that can tolerate the risk of a bug reaching production can practice Continuous Deployment. A team that cannot — because the application handles financial transactions or medical records — should practice Continuous Delivery.

The regulatory environment. Some industries require human approval before production changes. Continuous Delivery preserves the approval. Continuous Deployment does not.

The team’s maturity. Continuous Deployment requires a mature pipeline, reliable tests, and comprehensive monitoring. A team that is new to CI/CD should start with Continuous Delivery and move to Continuous Deployment when the pipeline is proven.

The application’s architecture. A monolithic application with a single deployment unit is harder to deploy continuously than a microservices application with independent services. The smaller the deployment unit, the easier it is to deploy frequently.

The customer’s expectations. Some applications require zero downtime. Others can tolerate a maintenance window. Continuous Deployment requires zero-downtime deployment strategies like blue-green or canary. Continuous Delivery can use the same strategies, but it also allows a maintenance window if needed.

The two practices are not mutually exclusive. A team might practice Continuous Delivery for the core application and Continuous Deployment for the internal tools. The choice can be made per service, not per organization.

Complete Example Session

This session demonstrates the two pipelines side by side. The CI stages are identical. The CD stages diverge at the production deployment.

# ============================================
# PART 1: THE SHARED CI PIPELINE
# ============================================

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'

      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - run: npm run build

      - run: docker build -t my-app:${{ github.sha }} .
      - run: docker push my-registry/my-app:${{ github.sha }}

The CI pipeline is the same for both practices. It builds, tests, and packages the artifact.

# ============================================
# PART 2: CONTINUOUS DELIVERY PIPELINE
# ============================================

# .github/workflows/cd-delivery.yml
name: CD - Delivery

on:
  workflow_run:
    workflows: [CI]
    types: [completed]
    branches: [main]

jobs:
  deploy-staging:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    runs-on: ubuntu-latest
    environment: staging

    steps:
      - name: Deploy to staging
        run: |
          kubectl apply -f k8s/staging/
          kubectl rollout status deployment/my-app

      - name: Run acceptance tests
        run: npm run test:acceptance

      - name: Run smoke tests
        run: npm run test:smoke

  approve-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production-approval

    steps:
      - name: Wait for approval
        run: echo "Approval granted"

  deploy-production:
    needs: approve-production
    runs-on: ubuntu-latest
    environment: production

    steps:
      - name: Deploy to production
        run: |
          kubectl apply -f k8s/production/
          kubectl rollout status deployment/my-app

      - name: Verify deployment
        run: npm run test:health

      - name: Notify team
        run: |
          curl -X POST $SLACK_WEBHOOK \
            -d '{"text":"Deployed to production successfully"}'

The Continuous Delivery pipeline has a manual approval gate. The approve-production job requires an approval from the production-approval environment. The approver reviews the staging deployment and the test results. If the approval is granted, the pipeline proceeds to production.

# ============================================
# PART 3: CONTINUOUS DEPLOYMENT PIPELINE
# ============================================

# .github/workflows/cd-deployment.yml
name: CD - Deployment

on:
  workflow_run:
    workflows: [CI]
    types: [completed]
    branches: [main]

jobs:
  deploy-staging:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    runs-on: ubuntu-latest
    environment: staging

    steps:
      - name: Deploy to staging
        run: |
          kubectl apply -f k8s/staging/
          kubectl rollout status deployment/my-app

      - name: Run acceptance tests
        run: npm run test:acceptance

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production

    steps:
      - name: Deploy to production
        run: |
          kubectl apply -f k8s/production/
          kubectl rollout status deployment/my-app

      - name: Verify deployment
        run: npm run test:health

      - name: Monitor for anomalies
        run: npm run monitor:anomalies

      - name: Rollback if needed
        if: failure()
        run: |
          kubectl rollout undo deployment/my-app
          curl -X POST $SLACK_WEBHOOK \
            -d '{"text":"Rollback triggered"}'

The Continuous Deployment pipeline has no approval gate. The production deployment follows the staging deployment automatically. The pipeline includes an automated rollback step that triggers if the deployment fails or the monitoring detects an anomaly.

# ============================================
# PART 4: THE FEATURE FLAG
# ============================================

# In Continuous Deployment, new features are deployed behind feature flags.

# src/config/features.ts
export const features = {
  newCheckout: false,  // disabled until the team is ready
  darkMode: true,      // enabled
  betaDashboard: false, // enabled for a subset of users
};

# The feature flag is checked at runtime.
# The code is in production, but the feature is not enabled.
# The team can enable the feature without a new deployment.

# ============================================
# PART 5: THE MONITORING
# ============================================

# The monitoring stack:
# - Prometheus for metrics
# - Grafana for dashboards
# - Alertmanager for alerts
# - Sentry for error tracking

# The alerts trigger the rollback.
# The pipeline monitors the error rate after deployment.
# If the error rate exceeds the threshold, the rollback runs.

# ============================================
# PART 6: THE ROLLBACK
# ============================================

# Manual rollback (Continuous Delivery):
kubectl rollout undo deployment/my-app

# Automatic rollback (Continuous Deployment):
# The pipeline detects the failure and runs the rollback.
# The rollback is logged and reported.

# ============================================
# PART 7: THE DORA METRICS
# ============================================

# Deployment frequency:
#   Continuous Delivery: multiple per day (with approval)
#   Continuous Deployment: multiple per day (automatic)

# Lead time for changes:
#   Continuous Delivery: commit to staging (automatic) + approval time
#   Continuous Deployment: commit to production (automatic)

# Mean time to recovery:
#   Continuous Delivery: manual rollback (minutes to hours)
#   Continuous Deployment: automatic rollback (seconds to minutes)

# Change failure rate:
#   Continuous Delivery: lower (human gate)
#   Continuous Deployment: higher (no human gate)

# ============================================
# PART 8: THE DECISION MATRIX
# ============================================

# Choose Continuous Delivery when:
# - The application handles sensitive data
# - The regulatory environment requires approval
# - The team is new to CI/CD
# - The pipeline is not yet proven
# - The risk of a bug reaching production is high

# Choose Continuous Deployment when:
# - The application is low-risk
# - The team is mature
# - The pipeline is proven
# - The monitoring is comprehensive
# - The rollback is automatic

# ============================================
# PART 9: THE HYBRID APPROACH
# ============================================

# Many teams use both:
# - Continuous Delivery for the core application
# - Continuous Deployment for internal tools
# - Continuous Delivery for the API
# - Continuous Deployment for the frontend

# The choice is per service, not per organization.

# ============================================
# PART 10: THE EVOLUTION
# ============================================

# Most teams start with Continuous Delivery.
# They build the pipeline.
# They prove the tests.
# They trust the monitoring.
# They reduce the approval time.
# Eventually, they remove the approval gate.
# They move to Continuous Deployment.
#
# The evolution is gradual.
# The destination is not the goal.
# The goal is fast, reliable, low-risk delivery.

The ten parts cover the shared CI pipeline, the Continuous Delivery pipeline, the Continuous Deployment pipeline, the feature flag, the monitoring, the rollback, the DORA metrics, the decision matrix, the hybrid approach, and the evolution.

Quick Reference

The Two Practices

Aspect	Continuous Delivery	Continuous Deployment
Approval gate	Manual	None
Production deployment	After approval	Automatic
Deployment frequency	Multiple per day (with approval)	Multiple per day (automatic)
Risk	Lower (human gate)	Higher (no gate)
Rollback	Manual or automated	Automated
Regulatory compliance	Compatible	Not always compatible
Team maturity	Moderate	High
Starting point	Recommended for most teams	Destination for mature teams

The Shared Pipeline Stages

Stage	Purpose
Source	Checkout code
Build	Compile and package
Test	Run automated tests
Lint	Static analysis
Package	Create artifact
Deploy Staging	Deploy to staging
Acceptance Tests	Verify in staging
Deploy Production	Deploy to production
Verify	Health checks

The Deployment Strategies

Strategy	Purpose
RollingUpdate	Gradual replacement
Blue-Green	Two environments, switch traffic
Canary	Subset of traffic to new version
Feature Flags	Deploy code, enable feature later

The DORA Metrics Comparison

Metric	Continuous Delivery	Continuous Deployment
Deployment frequency	High	Very high
Lead time	Includes approval time	Commit to production
MTTR	Manual rollback	Automatic rollback
Change failure rate	Lower	Higher

The Decision Factors

Factor	Continuous Delivery	Continuous Deployment
Risk tolerance	Low	High
Regulatory approval	Required	Not required
Team maturity	Moderate	High
Pipeline reliability	Proven	Fully trusted
Monitoring	Good	Comprehensive

Best Practices

✅ Do This:

# Use environment protection rules for production
environment: production                                          # ✅

# Run acceptance tests in staging before production
run: npm run test:acceptance                                     # ✅

# Automate the rollback
if: failure()
run: kubectl rollout undo deployment/my-app                      # ✅

# Use feature flags for gradual rollout
features: { newCheckout: false }                                 # ✅

# Monitor after deployment
run: npm run monitor:anomalies                                   # ✅

❌ Don’t Do This:

# Don't skip the staging deployment
# Every artifact should be validated in a production-like environment # ❌

# Don't deploy without monitoring
# You cannot detect failures without monitoring.                 # ❌

# Don't rebuild the artifact for production
docker build -t my-app:prod .  # rebuilds                         # ❌

# Don't enable Continuous Deployment before the pipeline is proven
# Start with Continuous Delivery.                                 # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Confusing CD with CD	Both abbreviate to CD	Use full names in documentation
No rollback plan	Never tested	Automate rollback, test it
Feature flags accumulate	Never cleaned up	Remove flags after rollout
Monitoring insufficient	Not configured	Add metrics, alerts, dashboards
Approval bottleneck	Manual process slow	Automate the approval workflow

Real-World Examples

1. Continuous Delivery Approval

environment: production-approval

2. Continuous Deployment Automatic

needs: deploy-staging
# no approval gate

3. Feature Flag

export const features = { newCheckout: false };

4. Rollback

kubectl rollout undo deployment/my-app

5. Staging Deployment

kubectl apply -f k8s/staging/

6. Production Deployment

kubectl apply -f k8s/production/

7. Acceptance Tests

npm run test:acceptance

8. Health Check

npm run test:health

9. Monitoring

# Prometheus + Grafana

10. DORA Metrics

# Deployment frequency, lead time, MTTR, change failure rate

Visual

The Continuous Delivery Pipeline

┌──────────────────────────────────────────────┐
│  CONTINUOUS DELIVERY                         │
│                                              │
│  CI Pipeline ──> Deploy Staging              │
│       │               │                      │
│       │               ▼                      │
│       │         Acceptance Tests             │
│       │               │                      │
│       │               ▼                      │
│       │         APPROVAL GATE                │
│       │               │                      │
│       │               ▼                      │
│       │         Deploy Production            │
│       │               │                      │
│       │               ▼                      │
│       │         Verify + Monitor             │
│                                              │
│  The human gate is the difference.           │
│                                              │
└──────────────────────────────────────────────┘

The Continuous Deployment Pipeline

┌──────────────────────────────────────────────┐
│  CONTINUOUS DEPLOYMENT                       │
│                                              │
│  CI Pipeline ──> Deploy Staging              │
│       │               │                      │
│       │               ▼                      │
│       │         Acceptance Tests             │
│       │               │                      │
│       │               ▼                      │
│       │         Deploy Production            │
│       │         (no gate)                    │
│       │               │                      │
│       │               ▼                      │
│       │         Verify + Monitor             │
│       │               │                      │
│       │               ▼                      │
│       │         Auto-Rollback                │
│                                              │
│  The pipeline is the only gate.              │
│                                              │
└──────────────────────────────────────────────┘

The DORA Metrics Comparison

┌──────────────────────────────────────────────┐
│  DORA METRICS                                │
│                                              │
│  Deployment frequency:                       │
│    CD (Delivery): high, with approval        │
│    CD (Deployment): very high, automatic     │
│                                              │
│  Lead time:                                  │
│    Delivery: commit to staging + approval    │
│    Deployment: commit to production          │
│                                              │
│  MTTR:                                       │
│    Delivery: manual rollback                 │
│    Deployment: automatic rollback            │
│                                              │
│  Change failure rate:                        │
│    Delivery: lower (human gate)              │
│    Deployment: higher (no gate)              │
│                                              │
└──────────────────────────────────────────────┘

The Evolution

┌──────────────────────────────────────────────┐
│  THE EVOLUTION                               │
│                                              │
│  Manual deployments                          │
│       │                                      │
│       ▼                                      │
│  Continuous Integration                      │
│       │                                      │
│       ▼                                      │
│  Continuous Delivery                         │
│       │                                      │
│       ▼                                      │
│  Continuous Deployment                       │
│                                              │
│  Each step builds on the previous.           │
│  The destination is not the goal.            │
│  The goal is fast, reliable delivery.        │
│                                              │
└──────────────────────────────────────────────┘

Summary

Item	Value
Continuous Delivery	Automated pipeline, manual approval for production
Continuous Deployment	Automated pipeline, automatic production deployment
Shared stages	Build, test, package, deploy staging, acceptance tests
Difference	The approval gate
Delivery risk	Lower (human gate)
Deployment risk	Higher (no gate)
Rollback	Manual (Delivery), automatic (Deployment)
Feature flags	Used in both, critical in Deployment
DORA metrics	Deployment frequency, lead time, MTTR, change failure rate
LFCA weight	DevOps Fundamentals, 12–16%

Key takeaways:

Continuous Delivery means every change that passes the pipeline is ready for production, but a human approves the deployment. The staging deployment and validation are automatic. The production deployment requires an approval .
Continuous Deployment means every change that passes the pipeline is deployed to production automatically. There is no human gate. The pipeline is the only gate .
The difference is the approval gate. Everything else in the pipeline is the same. Both require reliable tests, comprehensive monitoring, and rollback capability .
Continuous Delivery is the recommended starting point. Most teams should start with Delivery and move to Deployment when the pipeline is proven, the tests are reliable, and the team trusts the automation .
Continuous Deployment requires a mature pipeline. The tests must catch the bugs that would otherwise reach production. The monitoring must detect anomalies in real time. The rollback must be automatic .
Feature flags enable gradual rollout. In Continuous Deployment, new features are deployed behind feature flags. The code is in production, but the feature is not enabled. The team can enable the feature for a subset of users and expand the rollout gradually .
The choice can be per service. A team might practice Continuous Delivery for the core application and Continuous Deployment for internal tools. The choice depends on the risk profile of each service.

Remember: Continuous Delivery and Continuous Deployment share the same pipeline. The difference is the human gate. Delivery keeps the gate. Deployment removes it. Delivery is the starting point for most teams. Deployment is the destination for teams that have invested in test reliability, monitoring, and rollback automation. The two practices are not competing. They are stages in the same evolution toward faster, safer, more reliable software delivery.

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!