CI/CD Pipelines Explained: From Code Push to Automated Deployment

CI and CD: two distinct practices often bundled together

Continuous Integration (CI) is the practice of automatically building and testing code every time it is pushed. The goal is to catch integration problems — tests that fail, type errors, broken builds — immediately, before they are merged and before they affect other developers.

Continuous Delivery (CD) extends CI by automatically deploying the verified code to one or more environments. Continuous Delivery deploys to staging automatically and requires a manual approval for production. Continuous Deployment (also CD) goes further and deploys to production automatically on every passing build. Most teams use Continuous Delivery, not Continuous Deployment.

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

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

jobs:
  build-and-test:
    runs-on: ubuntu-latest       # the runner OS (also: windows-latest, macos-latest)

    steps:
      - name: Checkout code
        uses: actions/checkout@v4   # reusable action from GitHub Marketplace

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'             # cache node_modules between runs

      - name: Install dependencies
        run: npm ci                # ci installs exactly from package-lock.json

      - name: Type check
        run: npm run typecheck

      - name: Run tests
        run: npm test

      - name: Build
        run: npm run build

# Add secrets in GitHub: Settings → Secrets and variables → Actions → New secret
# Then reference them in your workflow as ${{ secrets.SECRET_NAME }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to server
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_SSH_KEY }}
          DATABASE_URL: ${{ secrets.PRODUCTION_DB_URL }}
          API_TOKEN: ${{ secrets.STRIPE_API_KEY }}
        run: |
          echo "$DEPLOY_KEY" > /tmp/deploy_key
          chmod 600 /tmp/deploy_key
          ssh -i /tmp/deploy_key user@server.example.com "cd /app && git pull && npm ci && pm2 restart all"

# GitHub automatically masks secret values in log output
# Any step that would print the value shows *** instead

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20', cache: 'npm' }
      - run: npm ci
      - run: npm test
      - run: npm run build

  deploy-staging:
    needs: test                    # only runs if test job passes
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/develop'   # only on develop branch
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to staging
        run: ./scripts/deploy.sh staging
        env:
          DEPLOY_TOKEN: ${{ secrets.STAGING_DEPLOY_TOKEN }}

  deploy-production:
    needs: [test, deploy-staging]  # both must pass
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'      # only on main branch
    environment: production        # requires manual approval in GitHub
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to production
        run: ./scripts/deploy.sh production
        env:
          DEPLOY_TOKEN: ${{ secrets.PROD_DEPLOY_TOKEN }}

# Method 1: Built-in cache in setup-node (simplest)
- uses: actions/setup-node@v4
  with:
    node-version: '20'
    cache: 'npm'          # also supports 'yarn' and 'pnpm'

# Method 2: Manual cache control (more flexibility)
- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

# Cache Docker layers between builds (useful for self-hosted runners)
- uses: docker/build-push-action@v5
  with:
    cache-from: type=gha
    cache-to: type=gha,mode=max

# Typical improvement: cold build 4 minutes → warm cache 45 seconds

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        node: [18, 20, 22]
      fail-fast: false   # continue other matrix jobs if one fails

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - run: npm ci
      - run: npm test

# This creates 9 parallel jobs (3 OS × 3 Node versions)
# Each runs independently and results are reported separately