CI/CD Pipeline Design Best Practices

CI/CD pipelines are slow, flaky, or don't catch real issues. Deployments are risky because the pipeline doesn't provide enough confidence.

Well-designed CI/CD pipeline structure:

# Stage 1: Fast feedback (< 2 min)
fast-checks:
  - lint (ESLint, Prettier, mypy)
  - type check (tsc --noEmit)
  - unit tests (fast, no I/O)
  - security scan (npm audit, trivy)

# Stage 2: Thorough validation (< 10 min)
integration:
  - integration tests (with test DB)
  - API contract tests
  - build verification
  needs: [fast-checks]

# Stage 3: Confidence (< 20 min)
confidence:
  - E2E tests (critical paths only)
  - performance benchmarks
  - accessibility checks
  needs: [integration]

# Stage 4: Deploy
deploy-staging:
  needs: [confidence]
  environment: staging

deploy-production:
  needs: [deploy-staging]
  environment: production
  # Manual approval or auto after staging soak

Principles:

1. Fast feedback first: Fail in seconds, not minutes
2. Parallelize: Run independent jobs concurrently
3. Cache aggressively: Node modules, build artifacts, Docker layers
4. Fail early: Put fastest, most-likely-to-fail checks first
5. No flaky tests: Fix or quarantine flaky tests immediately
6. Reproduce locally: Developers should be able to run the same checks locally
7. Branch protection: main requires passing CI + code review
8. Artifact promotion: Build once, deploy the same artifact to all environments

Anti-patterns to avoid:

• Running all tests sequentially
• No caching of dependencies
• Flaky tests that are retried instead of fixed
• Different build process for CI vs local
• Manual deployment steps

A good pipeline gives developers fast feedback and confidence to deploy. A bad pipeline is either too slow (developers avoid it) or too permissive (bugs reach production).

Designing effective CI/CD pipelines