ci-cd

CI/CD 流水线设置

此技能可帮助 Agent 设计、配置和维护 CI/CD 流水线，实现软件交付全生命周期的自动化。Agent 可以设置流水线阶段，包括代码检查、测试、构建、部署和通知相关人员，确保每次代码变更都经过验证并可靠交付。Agent 了解密钥管理、缓存策略、矩阵构建，以及蓝绿发布和金丝雀发布等部署策略。

工作流

1. 评估项目并选择平台： Agent 会分析项目使用的语言、框架、托管环境和团队偏好，推荐 CI/CD 平台。可选方案包括 GitHub Actions、GitLab CI/CD、Jenkins、CircleCI 和 Azure DevOps。Agent 会在推荐之前考虑代码库托管方式、成本、插件生态和与现有工具的集成等因素。

2. 定义流水线阶段： Agent 会将流水线划分为不同阶段：代码检查（静态分析和代码风格）、测试（单元测试、集成测试和端到端测试）、构建（编译、打包、创建 Docker 镜像）、部署（预发布环境和生产环境）以及通知（Slack、电子邮件或 webhook 警报）。每个阶段都有明确定义的输入、输出和失败条件，以便在出错时快速中止流水线。

3. 配置密钥和环境变量： Agent 会使用平台原生的密钥管理器（例如 GitHub Secrets、GitLab CI/CD Variables 或 Jenkins Credentials），安全存储 API 密钥、数据库凭据、云服务提供商令牌及其他敏感值。密钥绝不会硬编码在流水线文件中，并且会限定在相应的环境中。

4. 实现缓存和优化： Agent 会配置依赖项缓存（npm、pip、Maven）和构建产物缓存，以缩短流水线执行时间。矩阵构建可用于并行测试多个语言版本或操作系统。Agent 还会设置条件执行，使端到端测试等耗时阶段仅在相关分支上运行。

5. 配置部署策略： Agent 会根据项目的风险承受能力和基础设施实施适当的部署策略。可选方案包括滚动更新、蓝绿部署（在负载均衡器处切换两个相同的环境）以及金丝雀发布（逐步转移流量）。Agent 还会配置部署失败且健康检查未通过时的回滚流程。

6. 设置通知和监控： Agent 会配置流水线执行后的通知，通过 Slack、Microsoft Teams、电子邮件或自定义 webhook 向团队通报构建状态。部署事件会被记录，Agent 也可以集成监控工具，在每次部署后验证应用健康状况。

支持的技术

• 平台： GitHub Actions、GitLab CI/CD、Jenkins、CircleCI、Azure DevOps、Bitbucket Pipelines、Travis CI
• 语言： Node.js、Python、Java、Go、Rust、Ruby、.NET、PHP
• 容器化： Docker、Podman、Buildah
• 云服务提供商： AWS（ECS、EKS、Lambda）、GCP（Cloud Run、GKE）、Azure（App Service、AKS）
• 制品注册表： Docker Hub、GitHub Container Registry、AWS ECR、Google Artifact Registry

用法

向 Agent 提供项目所用的语言、框架、代码库托管平台、目标部署环境，以及测试框架或部署策略等具体要求。

提示词示例：

Set up a CI/CD pipeline for my Node.js Express app hosted on GitHub.
- Run ESLint and Prettier checks, then Jest unit tests
- Build a Docker image and push to GitHub Container Registry
- Deploy to AWS ECS staging on push to develop, production on push to main
- Send Slack notifications on failure

示例

示例 1：Node.js 应用的 GitHub Actions 工作流

name: CI/CD Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

env:
  NODE_VERSION: '20'
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run format:check

  test:
    runs-on: ubuntu-latest
    needs: lint
    strategy:
      matrix:
        node-version: [18, 20, 22]
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: testpass
          POSTGRES_DB: testdb
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npm test -- --coverage
        env:
          DATABASE_URL: postgres://postgres:testpass@localhost:5432/testdb
      - uses: actions/upload-artifact@v4
        with:
          name: coverage-${{ matrix.node-version }}
          path: coverage/

  build-and-push:
    runs-on: ubuntu-latest
    needs: test
    if: github.event_name == 'push'
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: |
            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}
            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max

  deploy-staging:
    runs-on: ubuntu-latest
    needs: build-and-push
    if: github.ref == 'refs/heads/develop'
    environment: staging
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1
      - run: |
          aws ecs update-service --cluster staging-cluster \
            --service my-app --force-new-deployment

  deploy-production:
    runs-on: ubuntu-latest
    needs: build-and-push
    if: github.ref == 'refs/heads/main'
    environment: production
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1
      - run: |
          aws ecs update-service --cluster production-cluster \
            --service my-app --force-new-deployment

  notify:
    runs-on: ubuntu-latest
    needs: [deploy-staging, deploy-production]
    if: always() && contains(needs.*.result, 'failure')
    steps:
      - uses: slackapi/[email protected]
        with:
          payload: |
            {"text": "Pipeline failed for ${{ github.repository }} on ${{ github.ref_name }}"}
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

示例 2：使用 Docker 的 Python 应用的 GitLab CI 流水线

stages:
  - lint
  - test
  - build
  - deploy

variables:
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.pip-cache"
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

cache:
  paths:
    - .pip-cache/
    - .venv/

lint:
  stage: lint
  image: python:3.12-slim
  script:
    - pip install ruff mypy
    - ruff check src/
    - mypy src/ --ignore-missing-imports

test:
  stage: test
  image: python:3.12-slim
  services:
    - postgres:16
  variables:
    POSTGRES_DB: testdb
    POSTGRES_PASSWORD: testpass
    DATABASE_URL: "postgresql://postgres:testpass@postgres:5432/testdb"
  script:
    - python -m venv .venv
    - source .venv/bin/activate
    - pip install -r requirements.txt -r requirements-dev.txt
    - pytest tests/ --cov=src --cov-report=xml
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage.xml

build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $DOCKER_IMAGE -t $CI_REGISTRY_IMAGE:latest .
    - docker push $DOCKER_IMAGE
    - docker push $CI_REGISTRY_IMAGE:latest

deploy_production:
  stage: deploy
  image: alpine:latest
  only:
    - main
  environment:
    name: production
    url: https://myapp.example.com
  before_script:
    - apk add --no-cache openssh-client
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | ssh-add -
  script:
    - ssh deploy@production-server "docker pull $DOCKER_IMAGE && docker-compose up -d"

最佳实践

• 快速失败： 对流水线阶段排序，先运行耗时较短的检查（lint、格式化），避免在本来就无法通过审查的代码上浪费计算资源。
• 固定操作和镜像版本： 始终为 CI 操作和 Docker 镜像使用特定版本标签（例如，actions/checkout@v4、python:3.12-slim），以确保构建可复现并避免供应链攻击。
• 严格限定机密的使用范围： 将机密限制在需要它们的环境和分支中。使用环境级保护规则，要求在部署到生产环境前进行人工审批。
• 充分利用缓存： 在不同流水线运行之间缓存依赖项安装、Docker 层和构建产物。在典型项目中，这可以将流水线耗时缩短 50% 或更多。
• 使用矩阵构建确保兼容性： 并行测试多个语言版本和操作系统，及早发现兼容性问题，同时不增加流水线的实际耗时。
• 设置部署关卡： 在将版本推广到生产环境之前，使用人工审批步骤、健康检查验证或金丝雀分析，以缩小不良部署的影响范围。

边缘情况

• 不稳定的测试： 间歇性通过的测试可能会阻塞流水线。对已知的不稳定测试实施重试逻辑，并跟踪不稳定性指标，以便优先修复。大多数 CI 平台都支持对单个作业使用 retry 指令。
• Monorepo 流水线： 在 Monorepo 中，对某项服务的更改不应触发与之无关的服务的流水线。使用基于路径的筛选器（例如，GitHub Actions 的 paths: 或 GitLab 的 changes:）来限定流水线触发范围。
• 速率限制和配额： Docker Hub、npm 和云 API 都设有速率限制。使用经过身份验证的拉取、私有镜像或缓存代理，避免流水线因受到限流而失败。
• 长时间运行的流水线： 超出平台时限的流水线（例如，GitHub Actions 的 6 小时作业时限）需要拆分为更小的作业，或使用时限更长的自托管运行器。
• 分支保护冲突： 如果 CI 流水线会将更改写回仓库（例如，自动格式化提交），可能会与分支保护规则冲突。使用专用的机器人令牌或应用级身份验证来推送更改。