一句话：CI/CD 是让代码从提交到上线自动化的流水线；CI 规范则是团队对"什么代码能合并、什么制品能发布、什么情况能上生产"的自动化门禁和约定。
一、CI/CD 是什么
| 概念 | 含义 | 关键点 |
|---|---|---|
| CI（持续集成） | 开发者频繁把代码合并到主干，每次提交自动构建、测试、检查 | 尽早发现集成问题，避免"合并地狱" |
| CD（持续交付） | CI 基础上，自动部署到预发/类生产环境，生产发布可人工审批 | 保证随时可发布 |
| CD（持续部署） | 变更通过所有门禁后自动上生产 | 对测试、监控、回滚要求很高 |
典型 CI/CD 流水线：
text
提交代码 -> 触发流水线 -> 检出代码 -> 安装依赖 -> Lint/类型检查
-> 单元测试 -> 构建 -> 集成测试 -> 安全扫描 -> 上传制品
-> 部署 Dev -> 部署 Staging -> 审批 -> 部署生产 -> 监控/回滚核心价值：快速反馈、减少手工、质量门禁、可重复发布、可回滚。
二、怎么设置 CI 规范
CI 规范不是只写一个 YAML，而是"流程约定 + 自动化门禁 + 度量改进"。
1. 分支与合并规范
推荐：
main为主干，必须保护：禁止直推、禁止 force push。- 功能分支：
feature/xxx、fix/xxx、hotfix/xxx。 - 所有变更走 PR/MR。
- 合并前必须满足：
- CI 全绿；
- 至少 1 人 review；
- 分支与主干同步；
- 无冲突；
- 关键项目要求 CODEOWNERS 审批。
GitHub 设置位置：Settings -> Branches -> Branch protection rules
GitLab：Settings -> Repository -> Protected branches + Merge request approvals
2. 提交与 PR 规范
- 提交信息建议用 Conventional Commits：
feat:、fix:、docs:、refactor:。 - PR 要小，最好一次只解决一个问题。
- PR 模板包含：变更内容、测试方式、影响范围、回滚方案。
- 禁止
[skip ci]绕过，除非纯文档且团队允许。
3. 流水线阶段与质量门禁
建议分阶段，先快后慢：
text
lint/format -> typecheck -> unit test -> build -> scan -> integration test -> deploy常见门禁：
- Lint/格式：0 error；
- 类型检查：通过；
- 单元测试：100% 通过；
- 覆盖率：新增代码 ≥ 80%，整体不下降；
- 构建：成功，且产物唯一、不可变；
- 安全扫描：无 Critical/High 漏洞；
- 依赖扫描：无高危依赖；
- 制品：上传到制品库，使用版本号或 commit SHA，不用
latest。
4. 触发规则
建议：
- PR 到
main：跑 lint、单测、构建、扫描； - push 到
main：构建制品，自动部署 Dev； - 打 tag，如
v1.2.3：部署 Staging，审批后上生产； - 定时任务： nightly 跑 E2E、性能、安全扫描。
5. 环境、密钥与权限
- 环境隔离：Dev、Staging、Prod。
- 配置外置，不硬编码。
- 密钥放 Secrets/Vault/KMS，禁止打印。
- CI 权限最小化，生产部署用 OIDC 短期凭证。
- 生产环境加人工审批，如 GitHub Environments、GitLab Protected Environments。
6. 部署与回滚
- 部署策略：滚动、蓝绿、金丝雀。
- 每次部署有唯一版本号，保留 N-1 版本。
- 健康检查失败自动回滚。
- 数据库迁移要向后兼容，建议 expand/contract。
- 生产发布必须有回滚方案和负责人。
7. 通知与度量
- 失败通知到 IM / 邮件。
- 跟踪 DORA 指标：
- 部署频率；
- 变更前置时间；
- 变更失败率；
- 平均恢复时间（MTTR）。
- Flaky 测试要治理，不能靠无限重试。
三、一个可落地的 CI 规范模板
text
# CI 规范
## 分支
- main 保护，禁止直推
- feature/* 开发，PR 合并
- hotfix/* 紧急修复
## PR 门禁
- 至少 1 人 review
- CI 必须全绿
- 新增代码覆盖率 ≥ 80%
- 无 Critical/High 漏洞
## 流水线
1. lint + typecheck
2. unit test
3. build
4. security scan
5. 上传制品
6. 部署 dev
7. 部署 staging
8. 人工审批后部署 prod
## 部署
- 使用不可变版本号
- 生产支持蓝绿/金丝雀
- 失败自动回滚
- 保留上一版本
## 密钥
- 禁止硬编码
- 使用 Secrets/Vault
- 生产审批 + 审计四、GitHub Actions 最小示例
yaml
name: ci
on:
pull_request:
push:
branches: [main]
permissions:
contents: read
concurrency:
group: ci-${{ github.ref }}
cancel-in-progress: true
jobs:
verify:
runs-on: ubuntu-latest
timeout-minutes: 15
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
- run: npm ci
- run: npm run lint
- run: npm run typecheck
- run: npm test -- --coverage
- run: npm run build然后在 GitHub 分支保护里把 verify 设为 Required status check 。生产部署可以另建 workflow，用 tag 触发，并绑定 production environment 做人工审批。
五、落地顺序建议
- 先做最小可用：PR 触发 lint + 单测。
- 加分支保护：CI 不过不能合并。
- 加构建和制品上传。
- 加 Dev/Staging 自动部署。
- 加安全扫描、覆盖率门禁。
- 加生产审批、金丝雀、自动回滚。
- 最后用 DORA 指标持续优化。
原则：先自动化，再门禁化，再标准化，最后度量优化。 不要一开始就设计过度复杂，否则 CI 会变成拖慢开发的瓶颈。