# GitHub Actions: Build once, push to registry, deploy to multiple environments
jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      image-tag: ${{ steps.meta.outputs.tags }}
    steps:
      - uses: actions/checkout@v4
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/org/app:${{ github.sha }}

  deploy-staging:
    needs: build
    uses: ./.github/workflows/deploy.yml
    with:
      environment: staging
      image-tag: ghcr.io/org/app:${{ github.sha }}

  deploy-production:
    needs: [build, deploy-staging]
    uses: ./.github/workflows/deploy.yml
    with:
      environment: production
      image-tag: ghcr.io/org/app:${{ github.sha }}

Testing Strategy in CI/CD

The Testing Pyramid in Practice

Unit Tests (base of pyramid): Run on every commit. These test individual functions, modules, and components in isolation. They should be fast (the entire suite under 2 minutes), deterministic (no flaky tests), and require no external dependencies (databases, APIs, file systems are mocked).

Integration Tests (middle): Run on every pull request. These test the interaction between components — API endpoint handlers with actual database queries, service-to-service communication, message queue producers and consumers. Use Docker Compose or Testcontainers to spin up real dependencies (PostgreSQL, Redis, Kafka) for these tests.

End-to-End Tests (top): Run before production deployment. These test critical user flows through the entire system — login, purchase, data processing, report generation. E2E tests are the most expensive to run and maintain. Limit them to 10-20 critical paths, not exhaustive coverage.

Parallel Test Execution

Split your test suite across multiple CI runners for parallelism. Most CI platforms support matrix strategies:

# GitHub Actions: Run tests in parallel across 4 shards
jobs:
  test:
    strategy:
      matrix:
        shard: [1, 2, 3, 4]
    steps:
      - run: |
          npx jest --shard=${{ matrix.shard }}/4

A 12-minute test suite split across 4 shards runs in 3 minutes. The cost of additional CI minutes is trivial compared to developer time saved.

Flaky Test Policy

Flaky tests — tests that pass and fail non-deterministically — are pipeline cancer. They erode trust in the CI system and train developers to ignore failures. Implement a zero-tolerance policy:

1. Quarantine flaky tests immediately — move them to a separate suite that runs but does not block merges
2. Track flaky test rate as a team metric (target: under 0.5% of total runs)
3. Fix or delete quarantined tests within one sprint
4. Never mark a flaky test as "expected to fail" and leave it

Security Integration: Shift Left

Security scanning belongs in CI, not as a monthly audit. Integrate these scans into every pipeline:

Static Application Security Testing (SAST)

Analyze source code for vulnerabilities without executing it. Tools: Semgrep, SonarQube, CodeQL (GitHub native).

- name: SAST scan
  uses: returntocorp/semgrep-action@v1
  with:
    config: >-
      p/default
      p/owasp-top-ten
      p/secrets

Software Composition Analysis (SCA)

Scan dependencies for known vulnerabilities. Tools: Snyk, Dependabot, Trivy.

- name: Dependency audit
  run: |
    npm audit --audit-level=high
    trivy fs --severity HIGH,CRITICAL --exit-code 1 .

Container Image Scanning

Scan built container images before pushing to registry.

- name: Scan container image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: ghcr.io/org/app:${{ github.sha }}
    severity: HIGH,CRITICAL
    exit-code: 1

Secret Detection

Prevent secrets from entering version control. Tools: Gitleaks, TruffleHog, GitHub secret scanning.

- name: Secret detection
  uses: gitleaks/gitleaks-action@v2
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Infrastructure as Code Scanning

Scan Terraform, CloudFormation, and Kubernetes manifests for misconfigurations. Tools: Checkov, tfsec, KICS.

- name: IaC scan
  uses: bridgecrewio/checkov-action@master
  with:
    directory: ./terraform
    framework: terraform
    soft_fail: false

Deployment Patterns

Rolling Deployment

The default for Kubernetes Deployments. Pods are replaced incrementally — new pods come up, pass health checks, receive traffic; old pods are drained and terminated. Simple, works for most applications.

Configuration that matters: - maxUnavailable: 0 — never reduce below desired count during deployment - maxSurge: 25% — allow 25% over desired count during transition - Readiness probes — pods do not receive traffic until healthy

Blue-Green Deployment

Run two identical environments. Route all traffic to "blue" (current). Deploy to "green" (new). Validate green. Switch the load balancer to green. Keep blue available for instant rollback.

Best for applications where database schema changes are backward-compatible and you need instant rollback capability. The cost is running double infrastructure during the deployment window.

Canary Deployment

Route a small percentage of traffic (1-5%) to the new version. Monitor error rates, latency, and business metrics. If metrics are healthy, progressively increase traffic (5% -> 25% -> 50% -> 100%). If metrics degrade, route all traffic back to the stable version.

Tools: Argo Rollouts, Flagger, AWS App Mesh, Istio traffic splitting.

# Argo Rollouts canary strategy
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: web-app
spec:
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: { duration: 5m }
        - setWeight: 25
        - pause: { duration: 10m }
        - setWeight: 50
        - pause: { duration: 10m }
        - setWeight: 100
      canaryMetrics:
        - name: error-rate
          successCondition: result[0] < 0.01
          provider:
            prometheus:
              query: |
                sum(rate(http_requests_total{status=~"5.*",app="web-app",version="canary"}[5m]))
                / sum(rate(http_requests_total{app="web-app",version="canary"}[5m]))

GitOps Deployment

GitOps uses a Git repository as the single source of truth for declarative infrastructure and application state. A controller (ArgoCD or Flux) running in the cluster watches the repository and applies changes automatically.

Benefits: - Every deployment is a Git commit with full audit trail - Rollback is git revert - Drift detection — if someone kubectl applys manually, the GitOps controller reverts it - Pull-based model — the cluster pulls config from Git, eliminating the need for CI to have cluster credentials

# ArgoCD Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/k8s-manifests.git
    path: apps/web-app/production
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Pipeline Optimization Techniques

Caching

Cache dependencies, build artifacts, and Docker layers aggressively.

# GitHub Actions: Cache node_modules
- uses: actions/cache@v4
  with:
    path: node_modules
    key: node-${{ hashFiles('package-lock.json') }}
    restore-keys: node-

# Docker layer caching
- uses: docker/build-push-action@v5
  with:
    cache-from: type=gha
    cache-to: type=gha,mode=max

Conditional Execution

Do not run the entire pipeline for every change. If only documentation changed, skip tests and builds.

on:
  push:
    paths-ignore:
      - 'docs/**'
      - '*.md'
      - '.github/ISSUE_TEMPLATE/**'

For monorepos, use path filters to run only the pipelines relevant to changed services:

jobs:
  detect-changes:
    outputs:
      api: ${{ steps.filter.outputs.api }}
      frontend: ${{ steps.filter.outputs.frontend }}
    steps:
      - uses: dorny/paths-filter@v3
        id: filter
        with:
          filters: |
            api:
              - 'services/api/**'
            frontend:
              - 'services/frontend/**'

  build-api:
    needs: detect-changes
    if: needs.detect-changes.outputs.api == 'true'
    # ...

Self-Hosted Runners

For large organizations, self-hosted CI runners (on EC2 Spot instances or GCP preemptible VMs) reduce costs by 60-80% compared to hosted runners and allow custom hardware configurations (GPU runners for ML pipelines, high-memory runners for integration tests).

Monitoring Your Pipeline

Track these metrics:

These align with the DORA metrics (DevOps Research and Assessment) that correlate with high-performing engineering organizations.

Building CI/CD Expertise

CI/CD is not a single tool to learn — it is a practice that spans version control, testing, security, deployment, and monitoring. The best pipelines evolve iteratively: start with build-and-test, add security scanning, implement progressive deployment, and layer in observability.

Citadel Cloud Management's DevOps courses cover CI/CD pipeline design from fundamentals through advanced GitOps patterns, including hands-on labs with GitHub Actions, ArgoCD, and Terraform. The DevOps Tools collection provides production-ready pipeline templates, Helm charts, and deployment configurations.

For teams building enterprise-grade pipelines with compliance requirements, the Security Frameworks collection includes CI/CD security scanning configurations, policy-as-code templates, and compliance automation playbooks.

Ready to build pipelines that ship code with confidence? Start with Citadel's free DevOps courses and progress from basic CI to production-grade GitOps deployments. Explore all toolkits and frameworks for battle-tested pipeline configurations.