CI-CD核心理念与流水线设计
1. 概念
CI（持续集成）：开发者频繁合并代码到主干，每次合并自动跑构建 + 测试，快速发现问题。
CD 含两层：
- 持续交付（Continuous Delivery）：自动构建出可发布产物，部署需手动触发
- 持续部署（Continuous Deployment）：合并即自动上线
前端工程的核心收益：
- 杜绝"我本地能跑"
- 每个 PR 都跑测试，避免回归
- 部署 = git tag，可回滚可追溯
- 减少人工操作出错
2. 完整流水线分层
代码 commit
↓
[Lint] ESLint / Prettier / TypeScript 编译检查
↓
[Unit Test] Jest / Vitest，覆盖率门禁
↓
[Build] 构建产物
↓
[Bundle Analyze] 体积变化检查（防 bundle 爆涨）
↓
[E2E Test] Playwright / Cypress（在 staging）
↓
[Container Build] Docker 镜像 + 推仓库
↓
[Image Scan] Trivy / Snyk 漏洞扫描
↓
[Deploy Staging] 自动
↓
[Smoke Test] staging 烟测
↓
[Deploy Production] 手动审批 / 自动（按团队约定）
↓
[Post-Deploy Verify] 健康检查 / 监控告警
3. 质量门（Quality Gate）
每个阶段必须通过才能进入下一步：
| 阶段 | 门禁 |
|---|---|
| Lint | 0 error |
| TypeScript | 0 error |
| Unit Test | 全过 + 覆盖率 ≥ 80% |
| Build | 0 error/warning |
| Bundle Size | 增长 < 5%（或绝对值 < 500KB） |
| Image Scan | 0 critical CVE |
| E2E | 关键路径 0 失败 |
# 例：失败阻断
- run: npm run lint
continue-on-error: false
- run: npm run test -- --coverage
- name: Coverage check
run: |
COV=$(jq '.total.lines.pct' coverage/coverage-summary.json)
if (( $(echo "$COV < 80" | bc -l) )); then
echo "Coverage $COV% < 80%"
exit 1
fi
4. 分支策略
4.1 GitHub Flow（前端常用）
main (永远可发布)
↑
└── feature-branch (PR 合并)
- 每个 feature 一个分支
- PR 跑 CI，过了 + review 才合
- 合并到 main 自动部署 staging
- 打 tag 部署 production
4.2 Git Flow（重型项目）
main → release/* → develop → feature/*
hotfix/*
复杂，前端少用。除非有严格版本周期。
4.3 Trunk-Based（高频部署）
只有 main，feature 用 feature flag 控制可见性。Google/Facebook 风格。要求 CI 极快、测试覆盖极高。
5. 流水线设计原则
5.1 Fail Fast
便宜快速的检查放前面：
lint (10s) → unit (1min) → build (3min) → e2e (10min)
lint 失败立即返回，不浪费 e2e 资源。
5.2 并行化
无依赖的 jobs 并行：
jobs:
lint: ...
unit-test: ...
type-check: ...
build:
needs: [lint, unit-test, type-check]
三个并行跑，时间 = max 而非 sum。
5.3 缓存复用
- npm cache（最大单点优化）
- Docker layer cache
- 构建产物（Turborepo / Nx）
CI 时间从 10 分钟降到 2 分钟。
5.4 幂等
相同输入相同输出。流水线可重跑、可重新部署。
5.5 可观测
每步耗时、失败原因清晰。不要把 5 个命令塞一个 step 里。
6. 工具选型
| 工具 | 特点 |
|---|---|
| GitHub Actions | GitHub 深度集成，社区 marketplace |
| GitLab CI | 自建友好，runner 灵活 |
| Jenkins | 老牌，插件多，UI 老旧 |
| CircleCI / Travis | 公有云老选择 |
| Drone | 开源轻量 |
| Buildkite | 自建 runner + SaaS 控制平面 |
| ArgoCD / Flux | GitOps 风格 CD |
前端开源项目用 GitHub Actions 几乎是默认。
7. 环境策略
| 环境 | 用途 |
|---|---|
| dev / preview | PR 自动建临时环境（Vercel preview 风格） |
| staging | main 分支部署 |
| production | git tag / 手动批准 |
每个环境独立的：
- 数据库（绝不共用 prod DB）
- 密钥（dev 不能拿到 prod token）
- 域名（preview-pr-42.staging.example.com）
8. 回滚策略
回滚比上线还重要。三种：
- 重新部署旧 tag：CI/CD 跑一次，慢
- K8s rollback：
kubectl rollout undo，秒级 - 流量切换：蓝绿/金丝雀，瞬时
监控 + 自动回滚（Argo Rollouts）：错误率超阈值自动 abort。
9. 常见反模式
- CI 跑 30 分钟：开发者绕过 CI 直推
- 测试不强制：自欺欺人
- 生产部署 = 一键发布按钮：无审批、无记录
- dev/staging/prod 数据库共用：测试改数据影响生产
- secrets 硬编码 yaml：泄露
- 流水线散落多个工具：维护噩梦
- 不做 PR preview：merge 后才发现 UI 坏
- 无回滚预案：出事拖几小时
10. 延伸阅读
- Continuous Delivery（书） — Jez Humble，CD 圣经
- DORA Metrics — 部署频率、变更前置时间、故障恢复、变更失败率
- The Twelve-Factor App — 现代应用部署原则