CI/CD Pipeline Engineering

Key Principles

• Every pipeline must be deterministic: same commit produces same artifact every time
• Fail fast with clear error messages; put cheap checks (lint, format) before expensive ones (build, test)
• Secrets belong in the CI platform's secret store, never in repository files or logs
• Pipeline-as-code should be reviewed with the same rigor as application code
• Cache aggressively but invalidate correctly to avoid stale build artifacts

Techniques

• Use GitHub Actions

  needs:

  to express job dependencies and enable parallel execution of independent jobs
• Define matrix builds with

  strategy.matrix

  for cross-platform and multi-version testing
• Configure

  actions/cache

  with hash-based keys (e.g.,

  hashFiles('**/package-lock.json')

  ) for dependency caching
• Write

  .gitlab-ci.yml

  with

  stages:

  ,

  rules:

  , and

  extends:

  for DRY pipeline definitions
• Structure Jenkins pipelines with

  Jenkinsfile

  declarative syntax:

  pipeline { agent, stages, post }

• Use

  workflow_dispatch

  inputs for manual triggers with parameterized deployments

Common Patterns

• Blue-Green Deployment: Maintain two identical environments; route traffic to the new one after health checks pass, keep the old one as instant rollback target
• Canary Release: Route a small percentage of traffic (1-5%) to the new version, monitor error rates and latency, then progressively increase if metrics are healthy
• Rolling Update: Replace instances one-at-a-time with

  maxUnavailable: 1

  and

  maxSurge: 1

  to maintain capacity during deployment
• Branch Protection Pipeline: Require status checks (lint, test, security scan) to pass before merge; use

  concurrency

  groups to cancel superseded runs

Pitfalls to Avoid

• Do not hardcode versions of CI runner images; pin to specific digests or semantic versions and update deliberately
• Do not skip security scanning steps to save time; integrate SAST/DAST as non-blocking checks initially, then make them blocking
• Do not use

  pull_request_target

  with checkout of PR head without understanding the security implications for secret exposure
• Do not allow pipeline definitions to drift between environments; use a single source of truth with environment-specific variables