mcpField
D
deployment-pipeline-design

deployment-pipeline-design

github.com/sickn33云与 DevOps48.8k239 次安装今天更新
代码仓库

关于 deployment-pipeline-design

用于设计多阶段 CI/CD 流水线的指导技能，涵盖审批关卡、部署策略、验证与回滚，适合规划部署流程的团队。它强调在生产环境发布前核验构建产物和运行状态。

主要功能

  1. 01多阶段流水线设计
  2. 02审批关卡模式
  3. 03滚动、蓝绿与金丝雀策略
  4. 04构建产物与发布验证
  5. 05回滚规划

适用场景

  1. 01设计 CI/CD 架构
  2. 02配置从预发布到生产的审批关卡
  3. 03规划渐进式部署
  4. 04制定发布检查与回滚条件

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill deployment-pipeline-design

安装后在 Claude Code 中输入/deployment-pipeline-design确认已加载。

详细介绍

部署流水线设计

适用于多阶段 CI/CD 流水线的架构模式，包括审批关卡和部署策略。

以下情况请勿使用此技能

  • 任务与部署流水线设计无关
  • 需要使用范围之外的其他领域或工具

说明

  • 明确目标、约束和所需输入。
  • 应用相关最佳实践并验证结果。
  • 提供可执行的步骤和验证方法。

目的

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

适用场景

  • 设计 CI/CD 架构
  • 实施部署关卡
  • 配置多环境流水线
  • 建立部署最佳实践
  • 实施渐进式交付

流水线阶段

标准流水线流程
┌─────────┐   ┌──────┐   ┌─────────┐   ┌────────┐   ┌──────────┐
│  Build  │ → │ Test │ → │ Staging │ → │ Approve│ → │Production│
└─────────┘   └──────┘   └─────────┘   └────────┘   └──────────┘
阶段详细说明
  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: Deploy to production
      run: |
        # Deployment commands
模式 2：延迟部署
# GitLab CI
deploy:production:
  stage: deploy
  script:
    - deploy.sh production
  environment:
    name: production
  when: delayed
  start_in: 30 minutes
  only:
    - main
模式 3：多审批人

配置平台实际的受保护环境审批策略，并核实哪些人可以审批或绕过该策略。对于 Azure，应将人工验证绑定到已安装的任务版本及其支持的无代理作业，而不是将其放入任意部署钩子中。记录所需的审批人和证据；仅发送通知并不等于审批。

部署策略

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

特点：

  • 逐步发布
  • 可用性取决于就绪状态、容量和变更兼容性
  • 易于回滚
  • 适用于大多数应用程序
2. 蓝绿部署
# Blue (current)
kubectl apply -f blue-deployment.yaml
kubectl patch service my-app --type merge -p '{"spec":{"selector":{"app":"my-app","version":"blue"}}}'

# Green (new)
kubectl apply -f green-deployment.yaml
# Test green environment
kubectl patch service my-app --type merge -p '{"spec":{"selector":{"app":"my-app","version":"green"}}}'

# Rollback if needed
kubectl patch service my-app --type merge -p '{"spec":{"selector":{"app":"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"):
    # New code path
    process_checkout_v2()
else:
    # Existing code path
    process_checkout_v1()

特点：

  • 部署但不发布
  • A/B 测试
  • 即时回滚
  • 精细控制

流水线编排

多阶段实施约定

只构建一次，记录提交和不可变制品摘要，在该制品上运行测试和安全检查，将其部署到获准的预发布环境，运行集成检查，取得已配置的生产审批，然后以有限的渐进式流量部署同一摘要。每个作业都必须自行检出代码、锁定工具、配置作用域受限的凭据并传输制品。在晋级前验证发布状态和应用指标；不要立即晋级金丝雀，从而跳过观察窗口。通知必须明确配置授权的接收者和目的地。

流水线最佳实践

  1. 快速失败 - 先运行快速测试
  2. 并行执行 - 并发运行相互独立的作业
  3. 缓存 - 在多次运行之间缓存依赖项
  4. 制品管理 - 存储构建制品
  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
手动回滚
# List revision history
kubectl rollout history deployment/my-app

# Rollback to previous version
kubectl rollout undo deployment/my-app

# Rollback to specific revision
kubectl rollout undo deployment/my-app --to-revision=3

监控和指标

关键流水线指标
  • 部署频率 - 部署发生的频率
  • 前置时间 - 从提交到部署至生产环境所需的时间
  • 变更失败率 - 部署失败的百分比
  • 平均恢复时间（MTTR） - 从故障中恢复所需的时间
  • 流水线成功率 - 成功运行的百分比
  • 平均流水线持续时间 - 完成流水线所需的时间
与监控集成

定义有测量依据的基线、最低流量、观测间隔和合理的阈值。使用有界超时查询经验证的指标端点，并验证提供方状态、结果结构和数值。缺失、空白或格式错误的指标意味着验证未完成，绝不能视为健康。验证不可用时，停止晋级并升级处理。固定等待时间和 Shell 比较无法证明部署健康。

审批与编排检查清单

将制品绑定到不可变的提交或镜像摘要，验证确切目标和现有部署标识，要求生产环境经过受保护环境审批，并记录健康标准和明确的回滚版本。每个作业都在独立的检出目录和运行时中执行；应传输已验证的制品，而不要假设前一个运行器的文件系统仍然可用。以下均为示意示例，并非完整的凭据或编排模板。无需未打包的操作手册。

相关技能

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

限制

  • 仅当任务明确符合上述范围时，才使用此技能。
  • 不要将输出视为环境特定验证、测试或专家审查的替代品。
  • 如果缺少必需的输入、权限、安全边界或成功标准，请停止并请求澄清。

评论

支持 Markdown