References: GitHub Actions official documentation, GitLab CI/CD documentation, Jenkins Pipeline documentation, DORA metrics, Continuous Delivery (Jez Humble).
Applicable Scenarios
- Setting up a CI/CD pipeline for a new project
- Optimizing an existing pipeline (speed / reliability)
- Multi-environment deployment strategy (dev → staging → prod)
- Security gate integration (SAST / DAST / dependency scanning)
- Monorepo pipeline design
- Automated release (semantic versioning)
Core Principles
1. 快速反馈
lint + unit test < 5 分钟
全流水线 < 15 分钟
-
Fail fast and block Any stage fails → do not proceed to the next stage Security scan HIGH → block deployment
-
Environment consistency CI environment = production environment (containerized) Do not depend on CI runner local state
-
Idempotent and retryable Consistent results on every run Any stage can be safely rerun
-
Least privilege Grant only necessary permissions at each stage secrets isolated by environment
-
Observable Each step has logs + duration Failures have clear error messages
-
Trunk-based development PR → CI → merge → CD Do not maintain long-lived branches
## 工作流程
```text
1. 确定流水线阶段
- lint(代码风格 + 静态分析)
- test(单元 + 集成)
- build(编译 + 打包 + 镜像)
- scan(安全扫描 + 许可证检查)
- deploy(按环境分级)
2. 选择 CI 平台
- GitHub Actions(GitHub 项目首选)
- GitLab CI(GitLab 项目首选)
- Jenkins(企业自建 / 复杂编排)
3. 设计触发规则
- PR:lint + test + build
- merge to main:全流程 + deploy staging
- tag:deploy production
- schedule:安全扫描 / 依赖更新
4. 配置缓存
- 依赖缓存(node_modules / .m2 / go mod)
- Docker 层缓存
- 构建产物缓存
5. 集成安全门禁
- SAST(Semgrep / CodeQL)
- 依赖扫描(Trivy / Snyk)
- 镜像扫描
- License 检查
6. 环境部署
- dev:自动部署(每次 merge)
- staging:自动部署 + 冒烟测试
- production:手动审批 / 自动(金丝雀)
7. 通知与报告
- 失败通知(Slack / Teams)
- 测试覆盖率报告
- 部署记录
Stage Details
| Stage | Tool | Duration Target | Failure Strategy |
|---|---|---|---|
| lint | ESLint / Prettier / golangci-lint | <1min | Block |
| test | Jest / pytest / go test | <5min | Block |
| build | Docker / webpack / go build | <3min | Block |
| scan | Trivy / Semgrep / CodeQL | <3min | HIGH blocks |
| deploy-staging | Helm / ArgoCD / Terraform | <5min | Block |
| smoke-test | Playwright / curl | <2min | Rollback |
| deploy-prod | Same as staging + approval | <5min | Rollback |
GitHub Actions Structure
# .github/workflows/ci.yml 核心结构
name: CI/CD
on:
pull_request:
branches: [main]
push:
branches: [main]
tags: ['v*']
jobs:
lint:
runs-on: ubuntu-latest
steps: [checkout, setup, lint]
test:
runs-on: ubuntu-latest
needs: lint
steps: [checkout, setup, test, coverage-upload]
build:
runs-on: ubuntu-latest
needs: test
steps: [checkout, docker-build, push-to-registry]
scan:
runs-on: ubuntu-latest
needs: build
steps: [trivy-scan, upload-sarif]
deploy-staging:
if: github.ref == 'refs/heads/main'
needs: [build, scan]
environment: staging
steps: [deploy, smoke-test]
deploy-prod:
if: startsWith(github.ref, 'refs/tags/v')
needs: [build, scan]
environment: production
steps: [deploy, verify]
Quality Self-Check
□ 流水线总耗时 < 15 分钟
□ lint + test 阶段 < 5 分钟
□ 依赖缓存已配置
□ Docker 层缓存已配置
□ 安全扫描集成(SAST + 依赖 + 镜像)
□ HIGH/CRITICAL 漏洞阻断部署
□ secrets 使用平台原生管理(不硬编码)
□ 环境隔离(dev / staging / prod)
□ 生产部署需审批或自动金丝雀
□ 失败通知已配置
□ 测试覆盖率有门槛
□ 流水线本身有版本控制
□ 可重试 / 幂等
Common Pitfalls
- No dependency caching——redownloaded on every CI run, doubling the time
- Hardcoded secrets——leaked to logs / repository
- CI environment inconsistent with production——passes locally, fails in CI
- No parallelization——running lint + test + build serially
- Unprotected tag triggers——anyone can push a tag to trigger deployment
- Not pinning action versions——uses: actions/checkout@main is unsafe
- Flaky tests——random failures erode trust
- No timeout settings——stuck jobs occupy runners
- Full monorepo builds——changing one package triggers everything
- No rollback for deploy——manual fixes after failure
- Not uploading artifacts——difficult to debug
- Chaotic branching strategy——merge conflicts on long-lived branches
Companion Templates
templates/github-actions-template.md— Complete GitHub Actions pipeline template
Collaboration with Other Skills
上游:
containerization → 镜像构建步骤
infrastructure-as-code → 部署基础设施
下游:
kubernetes-orchestration → 部署目标
release-strategy → 发布策略执行
monitoring-alerting → 部署后验证
secrets-config → CI secrets 管理