部署管道设计Skill deployment-pipeline-design

这个技能用于设计和实现多阶段CI/CD部署管道,包括批准门、安全检查、部署策略和监控。适用于架构部署工作流、设置持续交付或实施GitOps实践,帮助提高软件发布效率与安全性。关键词:CI/CD, 部署管道, 批准门, 安全扫描, 部署策略, GitOps, 云原生, DevOps。

CI/CD 0 次安装 0 次浏览 更新于 3/16/2026

名称: 部署管道设计 描述: 设计带有批准门、安全检查和部署编排的多阶段CI/CD管道。适用于架构部署工作流、设置持续交付或实施GitOps实践。

部署管道设计

多阶段CI/CD管道的架构模式,包括批准门和部署策略。

目的

设计健壮、安全的部署管道,通过适当的阶段组织和批准工作流平衡速度与安全。

何时使用

  • 设计CI/CD架构
  • 实施部署门
  • 配置多环境管道
  • 建立部署最佳实践
  • 实施渐进式交付

管道阶段

标准管道流程

┌─────────┐   ┌──────┐   ┌─────────┐   ┌────────┐   ┌──────────┐
│  构建  │ → │ 测试 │ → │ 预发布 │ → │ 批准 │ → │ 生产 │
└─────────┘   └──────┘   └─────────┘   └────────┘   └──────────┘

详细阶段分解

  1. 源代码 - 代码检出
  2. 构建 - 编译、打包、容器化
  3. 测试 - 单元测试、集成测试、安全扫描
  4. 预发布部署 - 部署到预发布环境
  5. 集成测试 - 端到端测试、冒烟测试
  6. 批准门 - 需要手动批准
  7. 生产部署 - 金丝雀部署、蓝绿部署、滚动部署
  8. 验证 - 健康检查、监控
  9. 回滚 - 失败时自动回滚

批准门模式

模式 1: 手动批准

# GitHub Actions
production-deploy:
  needs: staging-deploy
  environment:
    name: production
    url: https://app.example.com
  runs-on: ubuntu-latest
  steps:
    - name: 部署到生产
      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: '批准前查看预发布指标'

参考: 参见 assets/approval-gate-template.yml

部署策略

1. 滚动部署

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

特点:

  • 逐步发布
  • 零停机时间
  • 易于回滚
  • 适用于大多数应用

2. 蓝绿部署

# 蓝 (当前)
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. 金丝雀部署

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

特点:

  • 逐步流量转移
  • 风险缓解
  • 真实用户测试
  • 需要服务网格或类似技术

4. 功能标志

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: 生产管道

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 构建应用
        run: make build
      - name: 构建 Docker 镜像
        run: docker build -t myapp:${{ github.sha }} .
      - name: 推送到注册表
        run: docker push myapp:${{ github.sha }}

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: 单元测试
        run: make test
      - name: 安全扫描
        run: trivy image myapp:${{ github.sha }}

  deploy-staging:
    needs: test
    runs-on: ubuntu-latest
    environment:
      name: staging
    steps:
      - name: 部署到预发布
        run: kubectl apply -f k8s/staging/

  integration-test:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - name: 运行端到端测试
        run: npm run test:e2e

  deploy-production:
    needs: integration-test
    runs-on: ubuntu-latest
    environment:
      name: production
    steps:
      - name: 金丝雀部署
        run: |
          kubectl apply -f k8s/production/
          kubectl argo rollouts promote my-app

  verify:
    needs: deploy-production
    runs-on: ubuntu-latest
    steps:
      - name: 健康检查
        run: curl -f https://app.example.com/health
      - name: 通知团队
        run: |
          curl -X POST ${{ secrets.SLACK_WEBHOOK }} \
            -d '{"text":"生产部署成功!"}'

管道最佳实践

  1. 快速失败 - 先运行快速测试
  2. 并行执行 - 并行运行独立作业
  3. 缓存 - 在运行之间缓存依赖项
  4. 工件管理 - 存储构建工件
  5. 环境一致性 - 保持环境一致
  6. 秘密管理 - 使用秘密存储(如Vault)
  7. 部署窗口 - 适当安排部署时间
  8. 监控集成 - 跟踪部署指标
  9. 回滚自动化 - 失败时自动回滚
  10. 文档 - 记录管道阶段

回滚策略

自动回滚

deploy-and-verify:
  steps:
    - name: 部署新版本
      run: kubectl apply -f k8s/

    - name: 等待发布状态
      run: kubectl rollout status deployment/my-app

    - name: 健康检查
      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: 失败时回滚
      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

监控和指标

关键管道指标

  • 部署频率 - 部署发生的频率
  • 前置时间 - 从提交到生产的时间
  • 变更失败率 - 失败部署的百分比
  • 平均恢复时间 (MTTR) - 从失败恢复的时间
  • 管道成功率 - 成功运行的百分比
  • 平均管道持续时间 - 完成管道所需的时间

与监控集成

- name: 部署后验证
  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"
      exit 1
    fi

参考文件

  • references/pipeline-orchestration.md - 复杂管道模式
  • assets/approval-gate-template.yml - 批准工作流模板

相关技能

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