CI/CD Best Practices for Modern Development Teams

According to DORA Research, elite engineering teams deploy 973× more frequently than low-performing ones, with 6,570× faster recovery from failures. The single biggest differentiator between elite and low-performing teams? CI/CD pipeline maturity. A great pipeline isn't a nice-to-have — it's your most important piece of infrastructure.

The Pipeline Stages That Matter

name: CI/CD Pipeline
on:
  push: { branches: [main] }
  pull_request: { branches: [main] }

jobs:
  # Stage 1: Fast checks (< 2 minutes)
  lint-and-type:
    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 run lint
      - run: npm run type-check

  # Stage 2: Tests (parallel)
  test:
    needs: lint-and-type
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16-alpine
        env: { POSTGRES_PASSWORD: test }
        options: --health-cmd pg_isready
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test -- --coverage

  # Stage 3: Build + deploy (only on main)
  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t myapp:${{ github.sha }} .
      - run: docker push myapp:${{ github.sha }}
      - run: kubectl set image deployment/app app=myapp:${{ github.sha }}

The 5 Pipeline Principles

• <strong>Fast feedback is everything.</strong> If your pipeline takes more than 10 minutes, developers stop waiting for it. Target under 5 minutes for the critical path.
• <strong>Fail fast.</strong> Run the cheapest checks first (lint, type-check) before expensive ones (integration tests, E2E). Parallelise where possible.
• <strong>Test in production-like conditions.</strong> Your CI environment should match production: same OS, same database version, same environment variables.
• <strong>Every commit is a potential release.</strong> If it passes CI, it should be deployable to production. No special "release branches" or manual steps.
• <strong>Never skip CI.</strong> Enforce branch protection rules. No direct pushes to main. No exceptions.

Deployment Strategies

Choose your deployment strategy based on your risk tolerance. Blue-green deployments spin up a new environment and switch traffic atomically — zero downtime, instant rollback. Canary deployments route a percentage of traffic to the new version first — catch issues before full rollout. Rolling deployments update pods one by one — simple, but rollback is slower. For most web apps, blue-green with a 5-minute validation window before completing the cutover is the right default.