ci-cd-pipeline-builder

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

CI/CD Pipeline Builder

CI/CD 流水线构建工具

Tier: POWERFUL Category: Engineering / DevOps Maintainer: Claude Skills Team
等级: POWERFUL 分类: 工程 / DevOps 维护者: Claude Skills Team

Overview

概述

Generate production-grade CI/CD pipelines from detected project stack signals. Analyzes lockfiles, manifests, and scripts to produce optimized pipelines with proper caching, matrix strategies, security scanning, and deployment gates. Supports GitHub Actions, GitLab CI, CircleCI, and Buildkite with deployment strategies including blue-green, canary, and rolling updates.
根据检测到的项目栈信号生成生产级CI/CD流水线。通过分析锁文件、清单文件和脚本,生成具备合理缓存、矩阵策略、安全扫描和部署门控的优化流水线。支持GitHub Actions、GitLab CI、CircleCI和Buildkite,提供蓝绿部署、金丝雀部署和滚动更新等部署策略。

Keywords

关键词

CI/CD, GitHub Actions, GitLab CI, pipeline, deployment, caching, matrix builds, blue-green deployment, canary deployment, security scanning, SAST, container builds, environment gates
CI/CD, GitHub Actions, GitLab CI, 流水线, 部署, 缓存, 矩阵构建, 蓝绿部署, 金丝雀部署, 安全扫描, SAST, 容器构建, 环境门控

Core Capabilities

核心能力

1. Stack Detection

1. 栈检测

  • Language/runtime detection from lockfiles and manifests
  • Package manager inference from lock file format
  • Build/test/lint command extraction from scripts
  • Framework detection (Next.js, FastAPI, Go modules, etc.)
  • Infrastructure detection (Docker, Kubernetes, Terraform)
  • 从锁文件和清单文件中检测语言/运行时环境
  • 根据锁文件格式推断包管理器
  • 从脚本中提取构建/测试/代码检查命令
  • 检测框架(Next.js、FastAPI、Go modules等)
  • 检测基础设施(Docker、Kubernetes、Terraform)

2. Pipeline Generation

2. 流水线生成

  • Lint, test, build, deploy stages with correct dependencies
  • Caching strategies matched to package manager
  • Matrix builds for multi-version support
  • Artifact passing between jobs
  • Conditional execution (path filters, branch rules)
  • 包含正确依赖关系的代码检查、测试、构建、部署阶段
  • 匹配包管理器的缓存策略
  • 支持多版本的矩阵构建
  • 任务间的工件传递
  • 条件执行(路径过滤、分支规则)

3. Deployment Strategies

3. 部署策略

  • Blue-green with instant rollback
  • Canary with percentage-based traffic shifting
  • Rolling updates with health checks
  • Feature flags integration
  • Manual approval gates for production
  • 支持即时回滚的蓝绿部署
  • 基于流量百分比切换的金丝雀部署
  • 带健康检查的滚动更新
  • 功能标志集成
  • 生产环境的手动审批门控

4. Security Integration

4. 安全集成

  • SAST scanning (CodeQL, Semgrep, Snyk)
  • Dependency vulnerability scanning
  • Container image scanning (Trivy, Grype)
  • Secret scanning in CI
  • SBOM generation
  • SAST扫描(CodeQL、Semgrep、Snyk)
  • 依赖漏洞扫描
  • 容器镜像扫描(Trivy、Grype)
  • CI中的密钥扫描
  • SBOM生成

When to Use

使用场景

  • Bootstrapping CI/CD for a new repository
  • Migrating between CI platforms
  • Optimizing slow or flaky pipelines
  • Adding deployment stages to an existing CI-only pipeline
  • Implementing security scanning in the pipeline
  • Setting up multi-environment deployment (staging, production)
  • 为新仓库初始化CI/CD流程
  • 在不同CI平台间迁移流水线
  • 优化缓慢或不稳定的流水线
  • 为现有仅CI的流水线添加部署阶段
  • 在流水线中实现安全扫描
  • 设置多环境部署(预发布、生产)

Stack Detection Heuristics

栈检测规则

File Found                    → Inference
─────────────────────────────────────────────────
package-lock.json             → Node.js + npm
pnpm-lock.yaml                → Node.js + pnpm
yarn.lock                     → Node.js + yarn
bun.lockb                     → Bun
requirements.txt / Pipfile    → Python + pip/pipenv
pyproject.toml + uv.lock      → Python + uv
poetry.lock                   → Python + poetry
go.mod                        → Go
Cargo.lock                    → Rust
Gemfile.lock                  → Ruby
composer.lock                 → PHP
next.config.*                 → Next.js (Node.js)
nuxt.config.*                 → Nuxt (Node.js)
Dockerfile                    → Container build needed
docker-compose.yml            → Multi-service setup
terraform/*.tf                → Infrastructure as Code
k8s/ or kubernetes/           → Kubernetes deployment
检测到的文件                    → 推断结果
─────────────────────────────────────────────────
package-lock.json             → Node.js + npm
pnpm-lock.yaml                → Node.js + pnpm
yarn.lock                     → Node.js + yarn
bun.lockb                     → Bun
requirements.txt / Pipfile    → Python + pip/pipenv
pyproject.toml + uv.lock      → Python + uv
poetry.lock                   → Python + poetry
go.mod                        → Go
Cargo.lock                    → Rust
Gemfile.lock                  → Ruby
composer.lock                 → PHP
next.config.*                 → Next.js (Node.js)
nuxt.config.*                 → Nuxt (Node.js)
Dockerfile                    → 需要容器构建
docker-compose.yml            → 多服务部署
terraform/*.tf                → 基础设施即代码
k8s/ or kubernetes/           → Kubernetes部署

GitHub Actions Pipeline Templates

GitHub Actions 流水线模板

Node.js (pnpm + Vitest + Next.js)

Node.js (pnpm + Vitest + Next.js)

yaml
name: CI/CD

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

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

env:
  NODE_VERSION: '20'
  PNPM_VERSION: '9'

jobs:
  lint-and-typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
        with:
          version: ${{ env.PNPM_VERSION }}
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'pnpm'
      - run: pnpm install --frozen-lockfile
      - run: pnpm lint
      - run: pnpm typecheck

  test:
    runs-on: ubuntu-latest
    needs: lint-and-typecheck
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_USER: test
          POSTGRES_PASSWORD: test
          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: pnpm/action-setup@v4
        with:
          version: ${{ env.PNPM_VERSION }}
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'pnpm'
      - run: pnpm install --frozen-lockfile
      - run: pnpm test:ci
        env:
          DATABASE_URL: postgresql://test:test@localhost:5432/testdb

  build:
    runs-on: ubuntu-latest
    needs: test
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
        with:
          version: ${{ env.PNPM_VERSION }}
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'pnpm'
      - run: pnpm install --frozen-lockfile
      - run: pnpm build
      - uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: .next/
          retention-days: 1

  security-scan:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript-typescript
      - uses: github/codeql-action/analyze@v3

  deploy-staging:
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    needs: [build, security-scan]
    runs-on: ubuntu-latest
    environment:
      name: staging
      url: https://staging.myapp.com
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: build-output
          path: .next/
      - name: Deploy to staging
        run: |
          # Replace with your deployment command
          echo "Deploying to staging..."
        env:
          DEPLOY_TOKEN: ${{ secrets.STAGING_DEPLOY_TOKEN }}

  deploy-production:
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://myapp.com
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: build-output
          path: .next/
      - name: Deploy to production
        run: |
          echo "Deploying to production..."
        env:
          DEPLOY_TOKEN: ${{ secrets.PROD_DEPLOY_TOKEN }}
yaml
name: CI/CD

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

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

env:
  NODE_VERSION: '20'
  PNPM_VERSION: '9'

jobs:
  lint-and-typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
        with:
          version: ${{ env.PNPM_VERSION }}
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'pnpm'
      - run: pnpm install --frozen-lockfile
      - run: pnpm lint
      - run: pnpm typecheck

  test:
    runs-on: ubuntu-latest
    needs: lint-and-typecheck
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_USER: test
          POSTGRES_PASSWORD: test
          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: pnpm/action-setup@v4
        with:
          version: ${{ env.PNPM_VERSION }}
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'pnpm'
      - run: pnpm install --frozen-lockfile
      - run: pnpm test:ci
        env:
          DATABASE_URL: postgresql://test:test@localhost:5432/testdb

  build:
    runs-on: ubuntu-latest
    needs: test
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
        with:
          version: ${{ env.PNPM_VERSION }}
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'pnpm'
      - run: pnpm install --frozen-lockfile
      - run: pnpm build
      - uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: .next/
          retention-days: 1

  security-scan:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript-typescript
      - uses: github/codeql-action/analyze@v3

  deploy-staging:
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    needs: [build, security-scan]
    runs-on: ubuntu-latest
    environment:
      name: staging
      url: https://staging.myapp.com
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: build-output
          path: .next/
      - name: 部署到预发布环境
        run: |
          # 替换为你的部署命令
          echo "正在部署到预发布环境..."
        env:
          DEPLOY_TOKEN: ${{ secrets.STAGING_DEPLOY_TOKEN }}

  deploy-production:
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://myapp.com
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: build-output
          path: .next/
      - name: 部署到生产环境
        run: |
          echo "正在部署到生产环境..."
        env:
          DEPLOY_TOKEN: ${{ secrets.PROD_DEPLOY_TOKEN }}

Python (uv + pytest + FastAPI)

Python (uv + pytest + FastAPI)

yaml
name: CI/CD

on:
  push:
    branches: [main]
  pull_request:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v4
      - run: uv sync --frozen
      - run: uv run ruff check .
      - run: uv run ruff format --check .
      - run: uv run mypy src/

  test:
    runs-on: ubuntu-latest
    needs: lint
    strategy:
      matrix:
        python-version: ['3.11', '3.12', '3.13']
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_USER: test
          POSTGRES_PASSWORD: test
          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: astral-sh/setup-uv@v4
        with:
          python-version: ${{ matrix.python-version }}
      - run: uv sync --frozen
      - run: uv run pytest --cov --cov-report=xml -v
        env:
          DATABASE_URL: postgresql://test:test@localhost:5432/testdb
      - uses: codecov/codecov-action@v4
        if: matrix.python-version == '3.12'
        with:
          file: coverage.xml

  build-container:
    needs: test
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          context: .
          push: ${{ github.ref == 'refs/heads/main' }}
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  container-scan:
    needs: build-container
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: ghcr.io/${{ github.repository }}:${{ github.sha }}
          severity: 'CRITICAL,HIGH'
          exit-code: '1'
yaml
name: CI/CD

on:
  push:
    branches: [main]
  pull_request:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v4
      - run: uv sync --frozen
      - run: uv run ruff check .
      - run: uv run ruff format --check .
      - run: uv run mypy src/

  test:
    runs-on: ubuntu-latest
    needs: lint
    strategy:
      matrix:
        python-version: ['3.11', '3.12', '3.13']
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_USER: test
          POSTGRES_PASSWORD: test
          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: astral-sh/setup-uv@v4
        with:
          python-version: ${{ matrix.python-version }}
      - run: uv sync --frozen
      - run: uv run pytest --cov --cov-report=xml -v
        env:
          DATABASE_URL: postgresql://test:test@localhost:5432/testdb
      - uses: codecov/codecov-action@v4
        if: matrix.python-version == '3.12'
        with:
          file: coverage.xml

  build-container:
    needs: test
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          context: .
          push: ${{ github.ref == 'refs/heads/main' }}
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  container-scan:
    needs: build-container
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: ghcr.io/${{ github.repository }}:${{ github.sha }}
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

Deployment Strategy Decision Framework

部署策略决策框架

How critical is zero-downtime?
├─ Critical (payment processing, real-time systems)
│  └─ BLUE-GREEN DEPLOYMENT
│     Pro: Instant rollback, zero-downtime guaranteed
│     Con: Requires 2x infrastructure during deployment
├─ Important but can tolerate brief errors
│  ├─ Need to validate with real traffic first?
│  │  └─ CANARY DEPLOYMENT
│  │     Pro: Test with small % of traffic before full rollout
│  │     Con: Complex routing, need observability for canary metrics
│  │
│  └─ Standard web app with health checks
│     └─ ROLLING UPDATE
│        Pro: Simple, built into K8s/ECS, gradual rollout
│        Con: Both versions serve traffic during rollout
└─ Development/staging environment
   └─ RECREATE (stop old, start new)
      Pro: Simplest, cleanest
      Con: Brief downtime during deployment
零停机的重要程度如何?
├─ 极高(支付处理、实时系统)
│  └─ 蓝绿部署
│     优势:即时回滚,保证零停机
│     劣势:部署期间需要两倍基础设施
├─ 重要但可容忍短暂错误
│  ├─ 是否需要先用真实流量验证?
│  │  └─ 金丝雀部署
│  │     优势:全量发布前用小比例流量测试
│  │     劣势:路由复杂,需要金丝雀指标监控
│  │
│  └─ 带健康检查的标准Web应用
│     └─ 滚动更新
│        优势:简单,内置在K8s/ECS中,逐步发布
│        劣势:发布期间新旧版本同时提供服务
└─ 开发/预发布环境
   └─ 重建(停止旧服务,启动新服务)
      优势:最简单、最干净
      劣势:部署期间会有短暂停机

Caching Strategy Reference

缓存策略参考

Package ManagerCache PathKey Pattern
npm
~/.npm
${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}
pnpmDetected by setup-node
cache: 'pnpm'
in setup-node
yarn
~/.cache/yarn
${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }}
pip
~/.cache/pip
${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}
uv
~/.cache/uv
Handled by setup-uv
Go
~/go/pkg/mod
${{ runner.os }}-go-${{ hashFiles('go.sum') }}
Cargo
~/.cargo/registry
${{ runner.os }}-cargo-${{ hashFiles('Cargo.lock') }}
DockerGHA cache
cache-from: type=gha
in build-push-action
包管理器缓存路径密钥模式
npm
~/.npm
${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}
pnpm由setup-node自动检测在setup-node中配置
cache: 'pnpm'
yarn
~/.cache/yarn
${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }}
pip
~/.cache/pip
${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}
uv
~/.cache/uv
由setup-uv自动处理
Go
~/go/pkg/mod
${{ runner.os }}-go-${{ hashFiles('go.sum') }}
Cargo
~/.cargo/registry
${{ runner.os }}-cargo-${{ hashFiles('Cargo.lock') }}
DockerGHA缓存在build-push-action中配置
cache-from: type=gha

Pipeline Optimization Techniques

流水线优化技巧

1. Path Filtering (Skip Unnecessary Runs)

1. 路径过滤(跳过不必要的运行)

yaml
on:
  push:
    paths:
      - 'src/**'
      - 'tests/**'
      - 'package.json'
      - 'pnpm-lock.yaml'
    paths-ignore:
      - '**.md'
      - 'docs/**'
      - '.github/ISSUE_TEMPLATE/**'
yaml
on:
  push:
    paths:
      - 'src/**'
      - 'tests/**'
      - 'package.json'
      - 'pnpm-lock.yaml'
    paths-ignore:
      - '**.md'
      - 'docs/**'
      - '.github/ISSUE_TEMPLATE/**'

2. Job Dependency Graph

2. 任务依赖关系图

lint ──────┐
           ├──→ test ──→ build ──→ deploy-staging ──→ deploy-production
typecheck ─┘                │
                            └──→ security-scan
代码检查 ──────┐
           ├──→ 测试 ──→ 构建 ──→ 预发布部署 ──→ 生产部署
类型检查 ─┘                │
                            └──→ 安全扫描

3. Matrix Strategy with Fail-Fast

3. 带快速失败的矩阵策略

yaml
strategy:
  fail-fast: true  # cancel all if one fails
  matrix:
    node-version: [18, 20, 22]
    os: [ubuntu-latest]
    include:
      - node-version: 20
        os: macos-latest  # test one combo on macOS
yaml
strategy:
  fail-fast: true  # 一个任务失败则取消所有任务
  matrix:
    node-version: [18, 20, 22]
    os: [ubuntu-latest]
    include:
      - node-version: 20
        os: macos-latest  # 在macOS上测试一组组合

GitLab CI Equivalent

GitLab CI 等效示例

yaml
stages:
  - validate
  - test
  - build
  - deploy

variables:
  NODE_VERSION: "20"

.node-setup: &node-setup
  image: node:${NODE_VERSION}
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
      - .pnpm-store/
  before_script:
    - corepack enable
    - pnpm install --frozen-lockfile

lint:
  stage: validate
  <<: *node-setup
  script:
    - pnpm lint
    - pnpm typecheck

test:
  stage: test
  <<: *node-setup
  services:
    - postgres:16
  variables:
    POSTGRES_DB: testdb
    POSTGRES_USER: test
    POSTGRES_PASSWORD: test
    DATABASE_URL: postgresql://test:test@postgres:5432/testdb
  script:
    - pnpm test:ci
  coverage: '/All files[^|]*\|[^|]*\s+([\d\.]+)/'

build:
  stage: build
  <<: *node-setup
  script:
    - pnpm build
  artifacts:
    paths:
      - .next/
    expire_in: 1 hour

deploy_staging:
  stage: deploy
  environment:
    name: staging
    url: https://staging.myapp.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  script:
    - echo "Deploy to staging"

deploy_production:
  stage: deploy
  environment:
    name: production
    url: https://myapp.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
  needs: [deploy_staging]
  script:
    - echo "Deploy to production"
yaml
stages:
  - validate
  - test
  - build
  - deploy

variables:
  NODE_VERSION: "20"

.node-setup: &node-setup
  image: node:${NODE_VERSION}
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
      - .pnpm-store/
  before_script:
    - corepack enable
    - pnpm install --frozen-lockfile

lint:
  stage: validate
  <<: *node-setup
  script:
    - pnpm lint
    - pnpm typecheck

test:
  stage: test
  <<: *node-setup
  services:
    - postgres:16
  variables:
    POSTGRES_DB: testdb
    POSTGRES_USER: test
    POSTGRES_PASSWORD: test
    DATABASE_URL: postgresql://test:test@postgres:5432/testdb
  script:
    - pnpm test:ci
  coverage: '/All files[^|]*\|[^|]*\s+([\d\.]+)/'

build:
  stage: build
  <<: *node-setup
  script:
    - pnpm build
  artifacts:
    paths:
      - .next/
    expire_in: 1 hour

deploy_staging:
  stage: deploy
  environment:
    name: staging
    url: https://staging.myapp.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  script:
    - echo "部署到预发布环境"

deploy_production:
  stage: deploy
  environment:
    name: production
    url: https://myapp.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
  needs: [deploy_staging]
  script:
    - echo "部署到生产环境"

Validation Checklist

验证清单

Before merging a generated pipeline:
  1. YAML parses without syntax errors
  2. All referenced commands exist in the repository (
    test
    ,
    lint
    ,
    build
    )
  3. Cache strategy matches the detected package manager
  4. Required secrets are documented (not embedded in YAML)
  5. Branch protection rules match organization policy
  6. Deployment jobs are gated by protected environments
  7. Security scanning runs on the appropriate code paths
  8. Artifact retention is set (do not keep build artifacts indefinitely)
  9. Concurrency group prevents duplicate runs on the same branch
  10. Path filters exclude documentation-only changes from full CI runs
合并生成的流水线前,请检查:
  1. YAML语法解析无错误
  2. 所有引用的命令在仓库中存在(
    test
    lint
    build
  3. 缓存策略与检测到的包管理器匹配
  4. 已记录所需密钥(未嵌入YAML中)
  5. 分支保护规则符合组织策略
  6. 部署任务受保护环境门控
  7. 安全扫描在正确的代码路径上运行
  8. 设置了工件保留期限(不要无限期保留构建工件)
  9. 并发组防止同一分支上的重复运行
  10. 路径过滤排除仅文档变更触发完整CI运行

Common Pitfalls

常见陷阱

  • Copying pipelines between projects without adapting to the actual stack
  • No concurrency control leading to redundant parallel runs on rapid pushes
  • Missing cache keys causing cache misses on every run (slow builds)
  • Running full matrix on every PR when only main needs multi-version testing
  • Hardcoding secrets in YAML instead of using CI secret stores
  • No path filtering so documentation changes trigger full build+test+deploy
  • Deploy jobs without environment gates allowing accidental production deployments
  • No artifact retention policy causing storage costs to grow indefinitely
  • 在项目间复制流水线而不适应实际栈环境
  • 无并发控制导致频繁推送时出现冗余并行运行
  • 缺少缓存密钥导致每次运行都缓存未命中(构建缓慢)
  • 每个PR都运行完整矩阵而实际上只有主分支需要多版本测试
  • 在YAML中硬编码密钥而不是使用CI密钥存储
  • 无路径过滤导致文档变更触发完整构建+测试+部署
  • 部署任务无环境门控导致意外生产部署
  • 无工件保留策略导致存储成本无限增长

Best Practices

最佳实践

  1. Detect stack first, then generate pipeline — never guess at build commands
  2. Keep the generated baseline under version control and customize incrementally
  3. One optimization at a time — add caching, then matrix, then split jobs
  4. Require green CI before any deployment job can execute
  5. Use protected environments for production credentials and manual approval gates
  6. Track pipeline duration and flakiness as first-class engineering metrics
  7. Separate deploy jobs from CI jobs to keep feedback fast for developers
  8. Regenerate the pipeline when the stack changes significantly (new language, new framework)
  1. 先检测栈,再生成流水线 —— 绝不猜测构建命令
  2. 将生成的基线纳入版本控制并逐步自定义
  3. 一次优化一项 —— 先添加缓存,再添加矩阵,再拆分任务
  4. 要求CI运行成功后才能执行部署任务
  5. 对生产凭证和手动审批门控使用受保护环境
  6. 将流水线时长和不稳定率作为首要工程指标跟踪
  7. 将部署任务与CI任务分离以保持开发者反馈速度
  8. 当栈发生重大变化时重新生成流水线(新语言、新框架)

Troubleshooting

故障排除

ProblemCauseSolution
Pipeline YAML fails validationIndentation errors or invalid key namesRun
yamllint
locally before committing; use the CI platform's built-in linter (e.g.,
act
for GitHub Actions,
gitlab-ci-lint
for GitLab)
Cache misses on every runCache key does not include the correct lockfile hashVerify the
hashFiles()
path matches the actual lockfile location; check the Caching Strategy Reference table above
Matrix build times explodeRunning full OS + version matrix on every PRRestrict the full matrix to
main
branch pushes; run a single representative version on PRs
Deployment job triggers on PRsMissing branch/event guard on deploy jobsAdd
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
or equivalent platform condition
Service containers fail to startHealth check misconfigured or image not foundPin the service image to a specific major version; confirm health check command exists in the image
Secret not available in workflowSecret not added to the repository or environment settingsAdd the secret via the CI platform's secrets UI; ensure the job references the correct
environment
name
Build artifact missing in deploy jobArtifact name mismatch or retention expiredEnsure
upload-artifact
and
download-artifact
use the same
name
value; set
retention-days
high enough to survive the full pipeline
问题原因解决方案
流水线YAML验证失败缩进错误或无效键名提交前本地运行
yamllint
;使用CI平台内置的检查工具(如GitHub Actions用
act
,GitLab用
gitlab-ci-lint
每次运行都缓存未命中缓存密钥未包含正确的锁文件哈希验证
hashFiles()
路径与实际锁文件位置匹配;参考上方的缓存策略参考表
矩阵构建时长激增每个PR都运行完整的操作系统+版本矩阵将完整矩阵限制在
main
分支推送时运行;PR上仅运行单个代表性版本
部署任务在PR上触发部署任务缺少分支/事件防护添加
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
或等效的平台条件
服务容器启动失败健康检查配置错误或镜像未找到将服务镜像固定到特定主版本;确认镜像中存在健康检查命令
工作流中无法获取密钥密钥未添加到仓库或环境设置中通过CI平台的密钥UI添加密钥;确保任务引用正确的
environment
名称
部署任务中缺少构建工件工件名称不匹配或保留期限已过确保
upload-artifact
download-artifact
使用相同的
name
值;设置足够长的
retention-days
以覆盖整个流水线运行时间

Success Criteria

成功标准

  • Pipeline generates valid YAML that passes platform-native linting on first attempt for detected stacks
  • Build times stay under 10 minutes for lint + test + build stages combined (excluding deploy)
  • Cache hit rate exceeds 90% on repeat runs with unchanged lockfiles
  • Security scanning (SAST + dependency + container) executes on every push to
    main
    without manual triggers
  • Deployment to staging is fully automated; production requires exactly one manual approval gate
  • Pipeline flakiness rate remains below 2% over a rolling 30-day window
  • Zero hardcoded secrets in generated pipeline YAML; all sensitive values reference platform secret stores
  • 为检测到的栈生成的YAML首次通过平台原生检查即有效
  • 代码检查+测试+构建阶段的总构建时长保持在10分钟以内(不包含部署)
  • 锁文件未变更时重复运行的缓存命中率超过90%
  • 安全扫描(SAST+依赖+容器)在每次推送到
    main
    分支时自动执行,无需手动触发
  • 预发布部署完全自动化;生产部署需要恰好一次手动审批
  • 流水线不稳定率在30天滚动窗口内保持在2%以下
  • 生成的流水线YAML中无硬编码密钥;所有敏感值均引用平台密钥存储

Scope & Limitations

范围与限制

This skill covers:
  • Generating CI/CD pipelines for GitHub Actions, GitLab CI, CircleCI, and Buildkite
  • Stack detection from lockfiles, manifests, Dockerfiles, and infrastructure-as-code definitions
  • Deployment strategy selection (blue-green, canary, rolling, recreate) with decision framework
  • Pipeline optimization including caching, matrix builds, path filtering, and concurrency control
This skill does NOT cover:
  • Runtime infrastructure provisioning or cloud resource management (see
    engineering/saas-scaffolder
    )
  • Application-level security hardening beyond CI-integrated scanning (see
    engineering/skill-security-auditor
    )
  • Monitoring, alerting, and observability configuration after deployment (see
    engineering/observability-designer
    )
  • Database migration orchestration during deployments (see
    engineering/migration-architect
    )
本工具涵盖:
  • 为GitHub Actions、GitLab CI、CircleCI和Buildkite生成CI/CD流水线
  • 从锁文件、清单文件、Dockerfile和基础设施即代码定义中检测栈
  • 部署策略选择(蓝绿、金丝雀、滚动、重建)及决策框架
  • 流水线优化,包括缓存、矩阵构建、路径过滤和并发控制
本工具不涵盖:
  • 运行时基础设施配置或云资源管理(请查看
    engineering/saas-scaffolder
  • CI集成扫描之外的应用级安全加固(请查看
    engineering/skill-security-auditor
  • 部署后的监控、告警和可观测性配置(请查看
    engineering/observability-designer
  • 部署期间的数据库迁移编排(请查看
    engineering/migration-architect

Integration Points

集成点

SkillIntegrationData Flow
engineering/dependency-auditor
Feeds vulnerability scan results into pipeline security gatesAuditor findings trigger pipeline failure or warning annotations
engineering/release-manager
Coordinates versioning and changelog with deploy stagesRelease tags drive conditional deployment job execution
engineering/observability-designer
Post-deploy health checks and alerting complement pipeline gatesPipeline triggers smoke tests; observability confirms deployment health
engineering/env-secrets-manager
Manages secrets referenced by pipeline environment variablesSecret rotation policies feed into pipeline secret store configuration
engineering/migration-architect
Database migrations run as a pre-deploy step in the pipelineMigration status gates the application deployment job
engineering/runbook-generator
Generates rollback runbooks aligned with deployment strategyPipeline failure triggers link to the relevant rollback runbook
工具集成方式数据流
engineering/dependency-auditor
将漏洞扫描结果传入流水线安全门控审计结果触发流水线失败或警告注释
engineering/release-manager
协调版本控制和变更日志与部署阶段发布标签驱动条件部署任务执行
engineering/observability-designer
部署后健康检查和告警补充流水线门控流水线触发冒烟测试;可观测性工具确认部署健康状态
engineering/env-secrets-manager
管理流水线环境变量引用的密钥密钥轮换策略传入流水线密钥存储配置
engineering/migration-architect
数据库迁移作为流水线中的预部署步骤运行迁移状态作为应用部署任务的门控
engineering/runbook-generator
根据部署策略生成回滚手册流水线失败触发相关回滚手册的链接