What Is CI/CD? Continuous Integration & Delivery Explained

The Problem CI/CD Solves: Manual Deployment Hell

Picture the release process at a typical software company in 2005. Once a week (or once a month), developers would freeze the codebase, merge all feature branches that had been building in isolation for weeks, and spend the next several days resolving conflicts. Then a release engineer would manually run tests, manually build binaries, manually upload files to servers, and manually verify each step in a deployment runbook.

Deployment days were feared. They were all-hands-on-deck events that regularly ran past midnight. A bug in the merged code could mean reverting days of work. The test suite (if it existed) was run manually and incompletely. The feedback loop between writing code and knowing if it worked in production was measured in weeks.

This was not exceptional — it was the norm. The horror stories are from companies you recognize today: Amazon deploying once every few weeks, Netflix terrified of their monolith, Flickr taking days to ship a CSS change.

CI/CD is the systematic solution. The insight from pioneers like Martin Fowler (whose 2000 essay "Continuous Integration" formalized the practice), Paul Duvall's 2007 book, and the DevOps movement that followed was simple: automate every step from commit to production, and run it on every single change, not just at release time.

Amazon now deploys to production on average every 11.7 seconds. Netflix ships code hundreds of times per day. GitHub deploys dozens of times daily to their own CI system. The difference is not more developers or more servers — it is CI/CD.

CI vs CD: Untangling the Terminology

The CI/CD acronym packs three distinct practices. Industry usage is sloppy — many people say "CI/CD" when they mean different things. Here is the precise breakdown:

Most teams practice Continuous Integration + Continuous Delivery (not Deployment). Full Continuous Deployment — no human approval step before production — requires very mature test coverage, feature flags, and monitoring. Facebook, GitHub, and Netflix deploy continuously; most enterprise teams stop at Continuous Delivery with a one-click production deploy button.

The distinction matters operationally: Continuous Delivery means you are always capable of deploying; Continuous Deployment means you are always deploying.

Anatomy of a CI/CD Pipeline

A pipeline is a sequence of automated stages. Each stage must pass before the next runs. A failure at any stage stops the pipeline and notifies the team. Here is a typical five-stage pipeline and what happens in each:

Git push / PR opened
         │
         ▼
┌─────────────────┐
│  1. SOURCE      │  Checkout code, detect changed files
└────────┬────────┘
         ▼
┌─────────────────┐
│  2. BUILD       │  Install deps, compile/transpile, lint, type-check
│                 │  Fail fast: catch syntax errors in ~60 seconds
└────────┬────────┘
         ▼
┌─────────────────┐
│  3. TEST        │  Unit tests → integration tests → e2e tests
│                 │  Parallelized: 500 tests in 2 min with 10 workers
└────────┬────────┘
         ▼
┌─────────────────┐
│  4. PACKAGE     │  Build Docker image, tag with git SHA, push to registry
│                 │  Vulnerability scan (Trivy, Snyk)
└────────┬────────┘
         ▼
┌─────────────────┐
│  5. DEPLOY      │  Deploy to staging → smoke tests → [manual gate]
│                 │  → production deploy (blue/green or canary)
└─────────────────┘

The ordering is intentional: fail fast, at the cheapest stage. A linting error caught in stage 2 (30 seconds) costs far less than discovering a production bug in stage 5 (minutes or hours of recovery). Put the fastest, most specific checks first; defer expensive end-to-end tests to later stages.

GitHub Actions: The Industry-Leading Choice

GitHub Actions reached 33% market share in the JetBrains 2025 CI/CD survey — the first time any tool surpassed Jenkins (28%) as the most-used CI system. The reason is obvious once you use it: workflows live in the same repository as code, require zero infrastructure, and have a marketplace of 21,000+ prebuilt Actions.

Here is a production-quality GitHub Actions workflow for a Node.js application — the kind of pipeline that replaces a 200-line Jenkins DSL with readable YAML:

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

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

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  # ── Job 1: Lint + Type Check (fast, runs in parallel with tests) ──
  quality:
    name: Code Quality
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'          # caches node_modules across runs

      - run: npm ci             # reproducible install (uses package-lock.json)
      - run: npm run lint       # ESLint
      - run: npm run typecheck  # tsc --noEmit

  # ── Job 2: Tests (runs in parallel with quality) ──
  test:
    name: Tests
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16-alpine
        env:
          POSTGRES_PASSWORD: test
          POSTGRES_DB: testdb
        options: >-
          --health-cmd pg_isready
          --health-interval 5s
          --health-timeout 5s
          --health-retries 5

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test
        env:
          DATABASE_URL: postgres://postgres:test@localhost:5432/testdb
          NODE_ENV: test

      - name: Upload coverage report
        uses: codecov/codecov-action@v4
        if: always()            # upload even if tests fail

  # ── Job 3: Build & Push Docker image (only on main) ──
  build:
    name: Build & Push Image
    needs: [quality, test]     # only runs after both jobs pass
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    outputs:
      image-tag: ${{ steps.meta.outputs.tags }}

    steps:
      - uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Log in to GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=sha,prefix=sha-    # e.g. sha-abc1234
            type=raw,value=latest,enable=${{ github.ref == 'refs/heads/main' }}

      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  # ── Job 4: Deploy to staging ──
  deploy-staging:
    name: Deploy to Staging
    needs: build
    runs-on: ubuntu-latest
    environment: staging        # requires environment protection rules in GitHub

    steps:
      - name: Deploy to staging
        run: |
          # Example: update Kubernetes deployment via kubectl
          kubectl set image deployment/myapp app=${{ needs.build.outputs.image-tag }}
          kubectl rollout status deployment/myapp --timeout=300s

A few patterns worth highlighting: needs: [quality, test] makes the build job wait for both parallel jobs to pass before running. The services: block spins up a PostgreSQL container that integration tests connect to — exactly like running locally but fully ephemeral. The environment: staging declaration enables GitHub's environment protection rules — required reviewers, deployment history, and secrets scoped to that environment.

For more on CI/CD pipeline architectures including deployment strategies, see our CI/CD pipeline guide.

CI/CD Tool Comparison: GitHub Actions vs Jenkins vs GitLab CI

Choosing a CI/CD tool in 2026 is largely determined by where your code lives. Per JetBrains 2025, the most common reason teams choose a CI tool is "it lives where our code lives."

Jenkins deserves a nuanced view. It dominated CI for a decade (2011–2020) but the maintenance overhead is real: plugin version conflicts, Groovy scripting quirks, and the Java ecosystem dependency. The JetBrains 2025 survey found cost was the second biggest CI decision factor after "code colocation" — Jenkins' $0/month price point still wins in cost-sensitive enterprises with existing infrastructure. But for greenfield projects and teams that want zero CI DevOps overhead, GitHub Actions or GitLab CI are the clear defaults.

Testing Strategy for CI Pipelines

CI only works if your tests are fast, reliable, and comprehensive. The testing pyramid, introduced by Mike Cohn, remains the best model for structuring tests in a pipeline:

            /─────────────────           /   E2E Tests (10%)       slow (minutes), high confidence
          /─────────────────────         /  Integration Tests       medium (~30 sec), tests service boundaries
        /       (20-30%)                /─────────────────────────      /     Unit Tests (60-70%)     fast (<1 sec each), hundreds of them
     ───────────────────────────────

# Rule: most tests should be unit tests. They are:
# - Fast: run 500 unit tests in 5 seconds with jest --runInBand
# - Cheap: no external services, no network calls
# - Informative: pinpoint exactly which function broke

# Integration tests: test against real services (DB, Redis, queue)
# Run in parallel using CI matrix strategy:
strategy:
  matrix:
    test-suite: [api, auth, payments]  # 3 jobs run in parallel

# E2E tests (Playwright, Cypress): only on staging, not every PR
# Cost: ~5-10 minutes. Worth it for smoke testing critical paths.
# Don't gate every merge on 10-minute Playwright runs.

A pipeline that runs unit tests in 90 seconds, integration tests in 3 minutes, and only blocks production deploys on E2E failures in staging is dramatically more useful than a 20-minute monolithic test suite that runs everything on every commit. Per Google's internal research (published in "Software Engineering at Google"), their CI system runs over 800 million test cases per day — practically achieved by aggressive test sharding and caching.

Deployment Strategies: Blue/Green, Canary, and Rolling

How you deploy matters as much as how you build. CD without a deployment strategy is reckless; with one, it becomes safe to deploy continuously.

Blue/Green Deployment

Maintain two identical production environments: Blue (current) and Green (new). Deploy the new version to Green, run smoke tests, then switch the load balancer to point traffic at Green. If anything goes wrong, flip back to Blue in seconds. Zero downtime; instant rollback. Cost: double the infrastructure during deployment.

Canary Release

Route a small percentage of traffic (1–5%) to the new version while the majority stays on the old. Monitor error rates, latency, and business metrics. Gradually increase traffic if metrics stay healthy. Roll back instantly by routing all traffic back. Used by Netflix, Amazon, and Facebook for every significant deployment.

# nginx canary routing: 5% to new version
upstream backend {
  server stable-backend   weight=95;
  server canary-backend   weight=5;
}

# Kubernetes: canary with 5% traffic split
# stable: 19 replicas | canary: 1 replica = 5% of traffic
# Adjust canary replicas as confidence grows: 1 → 5 → 19 → replace stable

Rolling Deployment

Replace instances one at a time (or in small batches). New pods come up, old pods drain. Kubernetes does this by default with strategy: type: RollingUpdate. Simple but slower rollback than blue/green — you have to roll forward through each instance to revert.

DORA Metrics: Measuring CI/CD Effectiveness

The DORA (DevOps Research and Assessment) program at Google — now in its 10th year — is the most rigorous published research on what engineering practices predict high performance. Their four metrics are the industry standard for measuring CI/CD health:

• Deployment Frequency

  How often you deploy to production. Elite teams: multiple times per day. High: once per week to once per day. Medium: once per month to once per week. Low: fewer than once per month.

• Lead Time for Changes

  Time from code committed to code running in production. Elite: under one hour. High: 1 day to 1 week. Medium: 1 month to 6 months. Low: over 6 months.

• Change Failure Rate

  Percentage of deployments causing a production incident requiring a hotfix or rollback. Elite: 0–5%. High: 5–10%. Medium/Low: 15–30%. Counter-intuitively, elite teams deploy more often AND have lower failure rates — CI/CD reduces risk.

• Mean Time to Recovery

  How quickly you restore service after a failure. Elite: under one hour. High: under one day. Medium: 1 day to 1 week. Low: over 1 month. Automated rollbacks and feature flags dramatically reduce MTTR.

The 2025 DORA State of DevOps Report (surveying 3,200 professionals across 1,100 organizations) found that elite performers are 2.5x more likely to meet their organizational performance targets than low performers. CI/CD investment is not a quality-of-life improvement — it is correlated with business outcomes.

Common CI/CD Pitfalls

Teams that implement CI/CD but do not see the promised benefits are usually hitting one of these patterns:

Flaky Tests

A test that sometimes passes and sometimes fails for reasons unrelated to your code. One flaky test destroys CI trust: developers start re-running pipelines hoping for a green run, bypassing the signal. Per Google's engineering research, flaky tests are the #1 CI health problem at scale. Fix them immediately — quarantine them rather than ignore them. A flaky test that you are monitoring is better than one you have learned to work around.

Long Pipeline Runtimes

Once a pipeline exceeds 20 minutes, developers context-switch away, merge conflicts accumulate, and the "fail fast" principle breaks down. Profile your pipeline: use GitHub Actions' built-in timeline view or CircleCI's test insights to find which jobs dominate. Solutions: parallelism (split tests across runners), caching (npm cache, Docker layer cache, test results), and not running expensive tests on every PR (run E2E only on merge to main).

Secrets in Pipeline YAML

Never hardcode credentials in workflow files or pass them as plaintext environment variables. Use your CI tool's secret management: GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials Store. Reference them as ${{ secrets.API_KEY }} — GitHub masks them in logs automatically. You can validate how your environment variables are structured before moving them into CI secrets.

Deploying Without Health Checks

A pipeline that deploys and immediately reports success — before checking whether the new version is actually serving traffic — is worse than useless. Always add a post-deploy health check step: hit your /health endpoint, check that the expected version is serving, and verify key business metrics are not regressing in the first 2 minutes. This is the difference between "deployed successfully" and "customers are receiving the new version successfully."

Frequently Asked Questions

Related Articles