ci-cd-pipeline-builder
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseCI/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 Manager | Cache Path | Key Pattern |
|---|---|---|
| npm | | |
| pnpm | Detected by setup-node | |
| yarn | | |
| pip | | |
| uv | | Handled by setup-uv |
| Go | | |
| Cargo | | |
| Docker | GHA cache | |
| 包管理器 | 缓存路径 | 密钥模式 |
|---|---|---|
| npm | | |
| pnpm | 由setup-node自动检测 | 在setup-node中配置 |
| yarn | | |
| pip | | |
| uv | | 由setup-uv自动处理 |
| Go | | |
| Cargo | | |
| Docker | GHA缓存 | 在build-push-action中配置 |
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 macOSyaml
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:
- YAML parses without syntax errors
- All referenced commands exist in the repository (,
test,lint)build - Cache strategy matches the detected package manager
- Required secrets are documented (not embedded in YAML)
- Branch protection rules match organization policy
- Deployment jobs are gated by protected environments
- Security scanning runs on the appropriate code paths
- Artifact retention is set (do not keep build artifacts indefinitely)
- Concurrency group prevents duplicate runs on the same branch
- Path filters exclude documentation-only changes from full CI runs
合并生成的流水线前,请检查:
- YAML语法解析无错误
- 所有引用的命令在仓库中存在(、
test、lint)build - 缓存策略与检测到的包管理器匹配
- 已记录所需密钥(未嵌入YAML中)
- 分支保护规则符合组织策略
- 部署任务受保护环境门控
- 安全扫描在正确的代码路径上运行
- 设置了工件保留期限(不要无限期保留构建工件)
- 并发组防止同一分支上的重复运行
- 路径过滤排除仅文档变更触发完整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
最佳实践
- Detect stack first, then generate pipeline — never guess at build commands
- Keep the generated baseline under version control and customize incrementally
- One optimization at a time — add caching, then matrix, then split jobs
- Require green CI before any deployment job can execute
- Use protected environments for production credentials and manual approval gates
- Track pipeline duration and flakiness as first-class engineering metrics
- Separate deploy jobs from CI jobs to keep feedback fast for developers
- Regenerate the pipeline when the stack changes significantly (new language, new framework)
- 先检测栈,再生成流水线 —— 绝不猜测构建命令
- 将生成的基线纳入版本控制并逐步自定义
- 一次优化一项 —— 先添加缓存,再添加矩阵,再拆分任务
- 要求CI运行成功后才能执行部署任务
- 对生产凭证和手动审批门控使用受保护环境
- 将流水线时长和不稳定率作为首要工程指标跟踪
- 将部署任务与CI任务分离以保持开发者反馈速度
- 当栈发生重大变化时重新生成流水线(新语言、新框架)
Troubleshooting
故障排除
| Problem | Cause | Solution |
|---|---|---|
| Pipeline YAML fails validation | Indentation errors or invalid key names | Run |
| Cache misses on every run | Cache key does not include the correct lockfile hash | Verify the |
| Matrix build times explode | Running full OS + version matrix on every PR | Restrict the full matrix to |
| Deployment job triggers on PRs | Missing branch/event guard on deploy jobs | Add |
| Service containers fail to start | Health check misconfigured or image not found | Pin the service image to a specific major version; confirm health check command exists in the image |
| Secret not available in workflow | Secret not added to the repository or environment settings | Add the secret via the CI platform's secrets UI; ensure the job references the correct |
| Build artifact missing in deploy job | Artifact name mismatch or retention expired | Ensure |
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 流水线YAML验证失败 | 缩进错误或无效键名 | 提交前本地运行 |
| 每次运行都缓存未命中 | 缓存密钥未包含正确的锁文件哈希 | 验证 |
| 矩阵构建时长激增 | 每个PR都运行完整的操作系统+版本矩阵 | 将完整矩阵限制在 |
| 部署任务在PR上触发 | 部署任务缺少分支/事件防护 | 添加 |
| 服务容器启动失败 | 健康检查配置错误或镜像未找到 | 将服务镜像固定到特定主版本;确认镜像中存在健康检查命令 |
| 工作流中无法获取密钥 | 密钥未添加到仓库或环境设置中 | 通过CI平台的密钥UI添加密钥;确保任务引用正确的 |
| 部署任务中缺少构建工件 | 工件名称不匹配或保留期限已过 | 确保 |
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 without manual triggers
main - 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
集成点
| Skill | Integration | Data Flow |
|---|---|---|
| Feeds vulnerability scan results into pipeline security gates | Auditor findings trigger pipeline failure or warning annotations |
| Coordinates versioning and changelog with deploy stages | Release tags drive conditional deployment job execution |
| Post-deploy health checks and alerting complement pipeline gates | Pipeline triggers smoke tests; observability confirms deployment health |
| Manages secrets referenced by pipeline environment variables | Secret rotation policies feed into pipeline secret store configuration |
| Database migrations run as a pre-deploy step in the pipeline | Migration status gates the application deployment job |
| Generates rollback runbooks aligned with deployment strategy | Pipeline failure triggers link to the relevant rollback runbook |
| 工具 | 集成方式 | 数据流 |
|---|---|---|
| 将漏洞扫描结果传入流水线安全门控 | 审计结果触发流水线失败或警告注释 |
| 协调版本控制和变更日志与部署阶段 | 发布标签驱动条件部署任务执行 |
| 部署后健康检查和告警补充流水线门控 | 流水线触发冒烟测试;可观测性工具确认部署健康状态 |
| 管理流水线环境变量引用的密钥 | 密钥轮换策略传入流水线密钥存储配置 |
| 数据库迁移作为流水线中的预部署步骤运行 | 迁移状态作为应用部署任务的门控 |
| 根据部署策略生成回滚手册 | 流水线失败触发相关回滚手册的链接 |