Deployment Pipeline Design

What This Skill Produces

• Pipeline configuration: Stage definitions, job dependencies, parallelism, and caching strategy
• Deployment strategy: Chosen rollout pattern with annotated configuration (canary weights, blue-green switchover, rolling parameters)
• Health check setup: Shallow vs deep readiness probes, post-deployment smoke test scripts
• Gate definitions: Automated metric thresholds and manual approval workflows
• Rollback plan: Automated rollback triggers and manual runbook steps

When to Use

• Design CI/CD architecture for a new service or platform migration
• Implement deployment gates between environments
• Configure multi-environment pipelines with mandatory security scanning
• Establish progressive delivery with canary or blue-green strategies
• Debug pipelines where stages succeed but production behavior is wrong
• Reduce mean time to recovery by automating rollback on metric degradation

Pipeline Stages

Standard Pipeline Flow

┌─────────┐   ┌──────┐   ┌─────────┐   ┌────────┐   ┌──────────┐
│  Build  │ → │ Test │ → │ Staging │ → │ Approve│ → │Production│
└─────────┘   └──────┘   └─────────┘   └────────┘   └──────────┘

Detailed Stage Breakdown

1. Source - Code checkout, dependency graph resolution
2. Build - Compile, package, containerize, sign artifacts
3. Test - Unit, integration, SAST/SCA security scans
4. Staging Deploy - Deploy to staging environment with smoke tests
5. Integration Tests - E2E, contract tests, performance baselines
6. Approval Gate - Manual or automated metric-based gate
7. Production Deploy - Canary, blue-green, or rolling strategy
8. Verification - Deep health checks, synthetic monitoring
9. Rollback - Automated rollback on failure signals

Approval Gate Patterns

Pattern 1: Manual Approval (GitHub Actions)

production-deploy:
  needs: staging-deploy
  environment:
    name: production
    url: https://app.example.com
  runs-on: ubuntu-latest
  steps:
    - name: Deploy to production
      run: kubectl apply -f k8s/production/

Environment protection rules in GitHub enforce required reviewers before this job starts. Configure reviewers at Settings → Environments → production → Required reviewers.

Pattern 2: Time-Based Approval (GitLab CI)