部署流水线设计

包含审批门禁和部署策略的多阶段 CI/CD 流水线架构模式。

目的

通过合理的阶段组织和审批工作流，设计出在速度与安全性之间取得平衡的稳健、安全的部署流水线。

使用场景

• 设计 CI/CD 架构
• 实施部署门禁 (Deployment Gates)
• 配置多环境流水线
• 建立部署最佳实践
• 实施渐进式交付 (Progressive Delivery)

流水线阶段

标准流水线流程

┌─────────┐   ┌──────┐   ┌─────────┐   ┌────────┐   ┌──────────┐
│  构建    │ → │ 测试  │ → │ 预发环境 │ → │  审批   │ → │ 生产环境  │
└─────────┘   └──────┘   └─────────┘   └────────┘   └──────────┘

详细阶段分解

1. 源码 (Source) – 代码检出
2. 构建 (Build) – 编译、打包、容器化
3. 测试 (Test) – 单元测试、集成测试、安全扫描
4. 预发部署 (Staging Deploy) – 部署到预发环境
5. 集成测试 (Integration Tests) – 端到端 (E2E)、冒烟测试
6. 审批门禁 (Approval Gate) – 需要人工审批
7. 生产部署 (Production Deploy) – 金丝雀、蓝绿、滚动部署
8. 验证 (Verification) – 健康检查、监控
9. 回滚 (Rollback) – 失败时自动回滚

审批门禁模式

模式 1: 手动审批

# 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: |
        # 部署命令

模式 2: 基于时间的审批

# GitLab CI
deploy:production:
  stage: deploy
  script:
    - deploy.sh production
  environment:
    name: production
  when: delayed
  start_in: 30 minutes
  only:
    - main

模式 3: 多人审批

# Azure Pipelines
stages:
  - stage: Production
    dependsOn: Staging
    jobs:
      - deployment: Deploy
        environment:
          name: production
          resourceType: Kubernetes
        strategy:
          runOnce:
            preDeploy:
              steps:
                - task: ManualValidation@0
                  inputs:
                    notifyUsers: "team-leads@example.com"
                    instructions: "Review staging metrics before approving"

参考: 查看 assets/approval-gate-template.yml

部署策略

1. 滚动部署 (Rolling Deployment)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1

特点:

• 渐进式发布
• 零停机时间
• 易于回滚
• 适用于大多数应用程序

2. 蓝绿部署 (Blue-Green Deployment)

# 蓝色 (当前)
kubectl apply -f blue-deployment.yaml
kubectl label service my-app version=blue

# 绿色 (新版本)
kubectl apply -f green-deployment.yaml
# 测试绿色环境
kubectl label service my-app version=green

# 如果需要则回滚
kubectl label service my-app version=blue

特点:

• 即时切换
• 易于回滚
• 暂时使基础设施成本翻倍
• 适合高风险部署

3. 金丝雀部署 (Canary Deployment)

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 25
        - pause: { duration: 5m }
        - setWeight: 50
        - pause: { duration: 5m }
        - setWeight: 100

特点:

• 渐进式流量转移
• 降低风险
• 真实用户测试
• 需要服务网格 (Service Mesh) 或类似技术

4. 功能开关 (Feature Flags)

from flagsmith import Flagsmith

flagsmith = Flagsmith(environment_key="API_KEY")

if flagsmith.has_feature("new_checkout_flow"):
    # 新代码路径
    process_checkout_v2()
else:
    # 现有代码路径
    process_checkout_v1()

特点:

• 部署与发布解耦
• A/B 测试支持
• 即时回滚
• 细粒度控制

流水线编排

多阶段流水线示例

name: Production Pipeline

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build application
        run: make build
      - name: Build Docker image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Push to registry
        run: docker push myapp:${{ github.sha }}

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Unit tests
        run: make test
      - name: Security scan
        run: trivy image myapp:${{ github.sha }}

  deploy-staging:
    needs: test
    runs-on: ubuntu-latest
    environment:
      name: staging
    steps:
      - name: Deploy to staging
        run: kubectl apply -f k8s/staging/

  integration-test:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - name: Run E2E tests
        run: npm run test:e2e

  deploy-production:
    needs: integration-test
    runs-on: ubuntu-latest
    environment:
      name: production
    steps:
      - name: Canary deployment
        run: |
          kubectl apply -f k8s/production/
          kubectl argo rollouts promote my-app

  verify:
    needs: deploy-production
    runs-on: ubuntu-latest
    steps:
      - name: Health check
        run: curl -f https://app.example.com/health
      - name: Notify team
        run: |
          curl -X POST ${{ secrets.SLACK_WEBHOOK }} \
            -d '{"text":"Production deployment successful!"}'

流水线最佳实践

1. 快速失败 (Fail fast) – 优先运行快速测试
2. 并行执行 – 并发运行独立的任务
3. 缓存机制 – 在多次运行间缓存依赖项
4. 制品管理 – 存储构建产物 (Artifacts)
5. 环境一致性 – 保持各环境配置一致
6. 密钥管理 – 使用密钥存储库 (如 Vault)
7. 部署窗口 – 合理安排部署时间
8. 监控集成 – 追踪部署指标
9. 自动回滚 – 失败时自动回滚
10. 文档化 – 记录流水线各阶段说明

回滚策略

自动回滚

deploy-and-verify:
  steps:
    - name: Deploy new version
      run: kubectl apply -f k8s/

    - name: Wait for rollout
      run: kubectl rollout status deployment/my-app

    - name: Health check
      id: health
      run: |
        for i in {1..10}; do
          if curl -sf https://app.example.com/health; then
            exit 0
          fi
          sleep 10
        done
        exit 1

    - name: Rollback on failure
      if: failure()
      run: kubectl rollout undo deployment/my-app

手动回滚

# 列出修订历史
kubectl rollout history deployment/my-app

# 回滚到上一个版本
kubectl rollout undo deployment/my-app

# 回滚到指定版本
kubectl rollout undo deployment/my-app --to-revision=3

监控与指标

关键流水线指标

• 部署频率 (Deployment Frequency) – 部署发生的频率
• 前置时间 (Lead Time) – 从提交代码到生产环境的时间
• 变更失败率 (Change Failure Rate) – 失败部署的百分比
• 平均恢复时间 (MTTR) – 从故障中恢复所需的时间
• 流水线成功率 – 成功运行的百分比
• 平均流水线耗时 – 完成流水线所需的时间

与监控系统集成

- name: Post-deployment verification
  run: |
    # 等待指标稳定
    sleep 60

    # 检查错误率
    ERROR_RATE=$(curl -s "$PROMETHEUS_URL/api/v1/query?query=rate(http_errors_total[5m])" | jq '.data.result[0].value[1]')

    if (( $(echo "$ERROR_RATE > 0.01" | bc -l) )); then
      echo "Error rate too high: $ERROR_RATE"
      exit 1
    fi

相关技能

• github-actions-templates – 用于 GitHub Actions 实现
• gitlab-ci-patterns – 用于 GitLab CI 实现
• secrets-management – 用于密钥处理