CI/CD

CI/CD is the practice of building, testing, and releasing software through an automated pipeline that runs on every change. Instead of batching weeks of work into a risky manual release, each commit is integrated into the main line, verified by machines within minutes, and promoted toward production by the same repeatable process. This hub defines the terms, shows the shape of a modern pipeline, and links to the detailed pages on platforms, deployment strategies, and pipeline security.

Terminology

The three terms are frequently conflated. They describe successively longer stretches of the path from commit to user.

CI is a prerequisite for either form of CD, and it delivers most of its value on its own: a team can run strong CI for years before automating production releases. The distinction between delivery and deployment is purely the final promotion step. Many teams practice continuous deployment for stateless services and continuous delivery for anything touching schemas, billing, or regulated data.

A related idea is trunk-based development: short-lived branches (hours to a day or two) merged frequently into main, with unfinished work hidden behind feature flags instead of long-running branches. CI only works as intended when integration is actually continuous. See Branching Strategies for how branch models interact with pipelines.

Anatomy of a Pipeline

A pipeline is a sequence of stages, each acting as a gate: if a stage fails, later stages do not run. Fast, cheap checks run first so most failures surface within a few minutes.

flowchart LR
    COMMIT["Commit / PR"] --> BUILD["Build<br/>compile, package"]
    BUILD --> TEST["Test<br/>unit, lint, types"]
    TEST --> SCAN["Security<br/>SCA, SAST, secrets"]
    SCAN --> ART[("Artifact registry<br/>signed + SBOM")]
    ART --> STAGE["Deploy to staging<br/>integration / E2E"]
    STAGE --> GATE{"Promote?"}
    GATE -->|"human approval<br/>(Continuous Delivery)"| PROD["Progressive rollout<br/>to production"]
    GATE -->|"automatic<br/>(Continuous Deployment)"| PROD
    PROD --> OBS["Observe<br/>metrics, SLOs"]
    OBS -.->|"regression"| RB["Automated rollback"]

Several principles apply regardless of platform:

• Build once, promote everywhere. The artifact that passed tests (a container image digest, a signed binary) is the exact artifact deployed to staging and production. Rebuilding per environment silently invalidates earlier test results.
• Everything as code. Pipeline definitions, infrastructure, and deployment manifests live in version control and are reviewed like application code.
• Fast feedback. A PR pipeline that takes longer than roughly 10 minutes starts to be ignored or batched around. Caching, parallelism, and test selection are how you keep it short (see Platforms & Pipeline Design).
• Least privilege. Pipelines hold production credentials and publish artifacts that everyone downstream trusts, which makes them a high-value target. Short-lived OIDC credentials and pinned dependencies are the baseline (see Security, GitOps & Operations).
• Reversibility. Every deployment strategy should have an automated path back to the previous version.

A Minimal Pipeline

A small but realistic GitHub Actions workflow for a Node.js service. It runs CI on every pull request and push, cancels superseded runs, and deploys from main into a protected production environment. That environment can require reviewers, which is what turns this from continuous deployment into continuous delivery.

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

on:
  push:
    branches: [main]
  pull_request:

# Default the GITHUB_TOKEN to read-only; widen per job only where needed.
permissions:
  contents: read

# A new push to the same branch cancels the run already in progress.
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 24        # current Active LTS
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

  deploy:
    needs: test                   # only runs if every test step passed
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    environment: production       # protection rules / required reviewers apply here
    permissions:
      contents: read
      id-token: write             # mint an OIDC token for keyless cloud auth
    steps:
      - uses: actions/checkout@v6
      - run: ./scripts/deploy.sh

For a supply-chain-hardened version of this workflow, pin each uses: reference to a full commit SHA rather than a tag. The security page explains why.

Maturity Path

Pipelines are usually built up incrementally. A common progression:

Guides in This Section

See Also

• Git Version Control — the commits that trigger every pipeline
• Branching Strategies — branch models and how they shape pipelines
• Docker — reproducible build environments and container artifacts
• Kubernetes — the platform most rollout strategies target
• Terraform — infrastructure as code in the pipeline
• Monorepo Architecture — affected-target builds and CI at scale
• Cybersecurity — broader context for pipeline and supply-chain security