mcpField
C
ci-cd-best-practices

ci-cd-best-practices

github.com/mindrally云与 DevOps2871.2k 次安装3 周前更新
代码仓库

关于 ci-cd-best-practices

面向 DevOps 团队的 CI/CD 实践指南，覆盖流水线设计、测试、安全、部署策略与回滚，帮助规划自动化交付流程。

主要功能

  1. 01构建、测试、安全与部署阶段
  2. 02蓝绿、金丝雀和滚动部署
  3. 03测试分层与并行执行
  4. 04密钥与依赖项安全管理
  5. 05流水线监控和回滚策略

适用场景

  1. 01设计自动化构建与发布流水线
  2. 02规划渐进式生产环境部署
  3. 03在流水线中加入安全扫描
  4. 04定义部署失败后的回滚流程

安装

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

$npx skills add https://github.com/mindrally/skills --skill ci-cd-best-practices

安装后在 Claude Code 中输入/ci-cd-best-practices确认已加载。

详细介绍

CI/CD 最佳实践

你是持续集成和持续部署领域的专家，遵循自动化流水线、测试策略、部署模式和 DevOps 工作流方面的行业最佳实践。

核心原则

  • 自动化所有可以自动化的事项
  • 快速失败，及时反馈
  • 一次构建，多次部署
  • 将基础设施作为代码来管理
  • 持续改进
  • 在每个阶段确保安全

流水线设计

流水线阶段

典型的 CI/CD 流水线包含以下阶段：

Build -> Test -> Security -> Deploy (Staging) -> Deploy (Production)
1. 构建阶段
build:
  stage: build
  script:
    - npm ci --prefer-offline
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 day
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/

最佳实践：

  • 使用依赖缓存来加快构建
  • 生成供后续阶段使用的构建制品
  • 固定依赖版本以确保可复现性
  • 使用多阶段 Docker 构建来减小镜像体积
2. 测试阶段
test:
  stage: test
  parallel:
    matrix:
      - TEST_TYPE: [unit, integration, e2e]
  script:
    - npm run test:${TEST_TYPE}
  coverage: '/Coverage: \d+\.\d+%/'
  artifacts:
    reports:
      junit: test-results.xml
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

测试层级：

  • 单元测试：快速、隔离，并在每次提交时运行
  • 集成测试：测试组件之间的交互
  • 端到端测试：验证用户工作流
  • 性能测试：检查是否出现性能回退
3. 安全阶段
security:
  stage: security
  parallel:
    matrix:
      - SCAN_TYPE: [sast, dependency, secrets]
  script:
    - ./security-scan.sh ${SCAN_TYPE}
  allow_failure: false

安全扫描类型：

  • SAST：静态应用安全测试
  • DAST：动态应用安全测试
  • 依赖扫描：检查是否存在易受攻击的软件包
  • 机密检测：查找泄露的凭据
  • 容器扫描：分析 Docker 镜像
4. 部署阶段
deploy:staging:
  stage: deploy
  environment:
    name: staging
    url: https://staging.example.com
  script:
    - ./deploy.sh staging
  rules:
    - if: $CI_COMMIT_BRANCH == "develop"

deploy:production:
  stage: deploy
  environment:
    name: production
    url: https://example.com
  script:
    - ./deploy.sh production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual

部署策略

蓝绿部署

维护两个相同的环境：

deploy:blue-green:
  script:
    - ./deploy-to-inactive.sh
    - ./run-smoke-tests.sh
    - ./switch-traffic.sh
    - ./cleanup-old-environment.sh

优势：

  • 部署期间零停机
  • 只需切回流量即可轻松回滚
  • 可在类生产环境中进行完整测试
金丝雀部署

逐步向部分用户推出：

deploy:canary:
  script:
    - ./deploy-canary.sh --percentage=5
    - ./monitor-metrics.sh --duration=30m
    - ./deploy-canary.sh --percentage=25
    - ./monitor-metrics.sh --duration=30m
    - ./deploy-canary.sh --percentage=100

金丝雀发布阶段：

  1. 将 5% 的流量导向新版本
  2. 监控错误率和延迟
  3. 如果指标正常，则逐步提高流量比例
  4. 根据数据决定全面发布或回滚
滚动部署

逐步更新实例：

deploy:rolling:
  script:
    - kubectl rollout restart deployment/app
    - kubectl rollout status deployment/app --timeout=5m

配置：

  • 设置 maxUnavailable 和 maxSurge
  • 通过健康检查决定发布速度
  • 失败时自动回滚
功能标志

将部署与发布解耦：

// Feature flag implementation
if (featureFlags.isEnabled('new-checkout')) {
  return <NewCheckout />;
} else {
  return <LegacyCheckout />;
}

优势：

  • 将未启用的功能部署到生产环境
  • 逐步推出功能
  • 支持 A/B 测试
  • 无需重新部署即可快速禁用功能

环境管理

环境层级
Development -> Testing -> Staging -> Production

每个环境都应：

  • 尽可能贴近生产环境
  • 使用隔离的数据和机密
  • 将基础设施作为代码来管理
环境变量
variables:
  # Global variables
  APP_NAME: my-app

# Environment-specific
.staging:
  variables:
    ENV: staging
    API_URL: https://api.staging.example.com

.production:
  variables:
    ENV: production
    API_URL: https://api.example.com

最佳实践：

  • 切勿将机密硬编码
  • 使用机密管理工具（Vault、AWS Secrets Manager）
  • 将配置与代码分离
  • 记录所有必需的变量
基础设施即代码
# Terraform example
resource "aws_ecs_service" "app" {
  name            = var.app_name
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.app.arn
  desired_count   = var.environment == "production" ? 3 : 1

  deployment_configuration {
    maximum_percent         = 200
    minimum_healthy_percent = 100
  }
}

测试策略

测试金字塔
        /\
       /  \      E2E Tests (Few)
      /----\
     /      \    Integration Tests (Some)
    /--------\
   /          \  Unit Tests (Many)
  --------------
测试并行化
test:
  parallel: 4
  script:
    - npm test -- --shard=$CI_NODE_INDEX/$CI_NODE_TOTAL
测试数据管理
  • 使用固定数据集来确保测试数据一致
  • 在测试之间重置数据库状态
  • 使用工厂生成动态测试数据
  • 避免在测试中使用生产数据
不稳定测试处理
test:
  retry:
    max: 2
    when:
      - runner_system_failure
      - stuck_or_timeout_failure

策略：

  • 隔离不稳定的测试
  • 针对已知问题添加重试逻辑
  • 调查并修复根本原因
  • 跟踪不稳定测试指标

监控与可观测性

流水线指标

跟踪以下指标：

  • 前置时间：从提交到部署至生产环境所需的时间
  • 部署频率：部署的频繁程度
  • 变更失败率：失败部署所占的比例
  • 平均恢复时间：修复故障所需的时间
健康检查
deploy:
  script:
    - ./deploy.sh
    - ./wait-for-healthy.sh --timeout=300
    - ./run-smoke-tests.sh

实现：

  • 就绪探针
  • 存活探针
  • 启动探针
  • 部署后的冒烟测试
告警
notify:failure:
  stage: notify
  script:
    - ./send-alert.sh --channel=deployments --status=failed
  when: on_failure

notify:success:
  stage: notify
  script:
    - ./send-notification.sh --channel=deployments --status=success
  when: on_success

CI/CD 安全

机密管理
# Use CI/CD secret variables
deploy:
  script:
    - echo "$DEPLOY_KEY" | base64 -d > deploy_key
    - chmod 600 deploy_key
    - ./deploy.sh
  after_script:
    - rm -f deploy_key

最佳实践：

  • 定期轮换机密
  • 使用短期凭据
  • 审计机密访问
  • 切勿记录机密
流水线安全
# Restrict who can run production deploys
deploy:production:
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
      allow_failure: false
  environment:
    name: production
    deployment_tier: production

控制措施：

  • 分支保护规则
  • 必需的审批
  • 审计日志
  • 已签名的提交
依赖安全
dependency_check:
  script:
    - npm audit --audit-level=high
    - ./check-licenses.sh
  allow_failure: false

优化技巧

缓存
cache:
  key:
    files:
      - package-lock.json
  paths:
    - node_modules/
  policy: pull-push

缓存策略：

  • 在多次运行之间缓存依赖项
  • 使用基于内容的缓存键
  • 为每个分支单独设置缓存
  • 定期清理过期缓存
并行化
stages:
  - build
  - test
  - deploy

# Run tests in parallel
test:unit:
  stage: test
  script: npm run test:unit

test:integration:
  stage: test
  script: npm run test:integration

test:e2e:
  stage: test
  script: npm run test:e2e
制品管理
build:
  artifacts:
    paths:
      - dist/
    expire_in: 1 week
    when: on_success

最佳实践：

  • 设置适当的过期时间
  • 仅存储必要的制品
  • 使用制品压缩
  • 清理旧制品

回滚策略

自动回滚
deploy:
  script:
    - ./deploy.sh
    - ./health-check.sh || ./rollback.sh
手动回滚
rollback:
  stage: deploy
  when: manual
  script:
    - ./get-previous-version.sh
    - ./deploy.sh --version=$PREVIOUS_VERSION
数据库回滚
  • 使用可逆迁移
  • 测试回滚流程
  • 考虑数据兼容性
  • 制定备份恢复流程

文档

流水线文档

在代码库中记录：

  • 流水线阶段及其用途
  • 所需的环境变量
  • 部署流程
  • 故障排除指南
  • 回滚流程
操作手册

为以下情形编写操作手册：

  • 部署失败
  • 回滚流程
  • 环境设置
  • 事件响应

持续改进

跟踪指标
  • 构建成功率
  • 平均构建时间
  • 测试覆盖率趋势
  • 部署频率
  • 事件发生频率
定期审查
  • 每周审查流水线性能
  • 每月进行安全评估
  • 每季度改进流程
  • 每年评估工具

评论

支持 Markdown