CI/CD Pipeline Architecture: Stages, Gates & Deployment Strategies

Complete 6-Stage Pipeline

A production-grade GitHub Actions pipeline with all six stages: source, build, test, security scan, deploy to staging, and deploy to production with manual approval gate.

name: Production Pipeline

on:
  push:
    branches: [main]

jobs:
  # Stage 1: Source — handled by checkout in each job

  # Stage 2 + 3: Build & Test (parallel)
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - uses: actions/upload-artifact@v4
        with: { name: dist, path: dist/ }

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test -- --coverage
      - name: Quality Gate — coverage must be ≥80%
        run: |
          COVERAGE=$(cat coverage/coverage-summary.json | jq '.total.lines.pct')
          if (( $(echo "$COVERAGE < 80" | bc -l) )); then
            echo "Coverage $COVERAGE% is below 80% threshold"; exit 1
          fi

  # Stage 4: Security
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm audit --audit-level=high
      - uses: github/codeql-action/analyze@v3

  # Stage 5: Deploy to Staging (auto)
  deploy-staging:
    needs: [build, test, security]
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/download-artifact@v4
        with: { name: dist }
      - run: ./scripts/deploy.sh staging

  # Stage 6: Deploy to Production (manual approval)
  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://example.com
    steps:
      - uses: actions/download-artifact@v4
        with: { name: dist }
      - run: ./scripts/deploy.sh production

Deployment Strategies Compared

The right deployment strategy depends on your tolerance for downtime, infrastructure budget, and traffic volume. Here is a concise comparison of the three main approaches.

# Blue-Green: two environments, instant traffic switch
# Infrastructure: 2x cost
# Rollback time: seconds (flip load balancer)
resource "aws_lb_listener_rule" "blue_green_switch" {
  action {
    type             = "forward"
    target_group_arn = var.active_env == "blue" ? aws_lb_target_group.blue.arn : aws_lb_target_group.green.arn
  }
}

# Canary: route % of traffic to new version
# Tools: AWS CodeDeploy, Argo Rollouts, Istio, nginx split_clients
# Monitor for 15min at 5%, then ramp to 50%, then 100%

# Rolling: replace instances gradually
# Kubernetes rolling update (default strategy)
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1         # add 1 new pod before removing old
    maxUnavailable: 0   # never reduce below desired count

GitOps with ArgoCD

In a GitOps pipeline, CI handles build and image push. Deployment is driven by a separate manifest repository watched by ArgoCD — any change to the manifests is automatically applied to the cluster.

# CI pipeline: build image and update manifest repo
- name: Build and push image
  run: |
    docker build -t myorg/app:$GITHUB_SHA .
    docker push myorg/app:$GITHUB_SHA

- name: Update manifest repository
  run: |
    git clone https://x-token:${{ secrets.MANIFEST_TOKEN }}@github.com/myorg/k8s-manifests.git
    cd k8s-manifests
    # Update image tag in Helm values
    yq e '.image.tag = "${{ github.sha }}"' -i apps/myapp/values.yaml
    git commit -am "chore: update myapp to ${{ github.sha }}"
    git push

# ArgoCD Application manifest (in k8s-manifests repo)
# argocd-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  source:
    repoURL: https://github.com/myorg/k8s-manifests
    path: apps/myapp
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Deployment Strategy Decision Matrix