每日Skill学习 — CI/CD Compliance#

1. CI 门禁序列（CI Gates Sequence）#

这是整个 skill 的核心——定义了一个标准化的检查序列：

1
install → lint/format → typecheck → unit → integration → (optional e2e) → package

每一步都是必须通过的”门禁”：

关键原则：顺序不可跳，每一步都 blocking。

2. 合并策略（Merge Policy）#

定义了代码合并到主分支的规则：

• 只有绿灯才能合并 — 所有 CI 门禁必须通过
• 合并后自动部署到 staging — 减少人工操作，降低出错概率
• 生产环境需要 tag 或审批 — 安全网，防止意外发布

这个策略其实体现了”渐进式发布”的思想：staging 是自动的、低风险的；production 是受控的、需要确认的。

3. CI 失败处理流程#

当 CI 检查失败时，skill 给出了明确的处理流程：

1. 在 PR 评论中解释根本原因 — 不只是报错，要说明”为什么”
2. 在同一个 PR 中修复问题（如果可行）— 不要把问题和修复分开，增加上下文
3. 门禁全部通过前不允许合并 — 这是硬性要求

这个流程的核心价值在于可追溯性。每个失败都有记录，每个修复都有对应关系。

4. IDE 集成建议#

对于使用 AI 辅助开发工具的开发者：

• AINative / Windsurf / Cursor / Claude Code：使用内置的代码操作和终端来运行测试/linter
• 优先使用 unified diffs：确保修改可以在不同 IDE 之间通用
• 断言时附带制品：测试输出、截图、日志——空口无凭，拿出证据

🔥 亮点#

1. 极简但有效 — 整个 skill 的规则可以用一句话概括：“先检查，再合并，有问题就说清楚”。简单不等于没用，反而更容易执行。

2. 阶段分离的哲学 — CI Gates 的序列设计体现了”从快到慢”的检查顺序。lint 和 typecheck 很快，先跑；e2e 很慢，放最后且可选。这样能在早期就拦截大部分问题，节省 CI 资源。

3. 失败处理的结构化 — 不只是告诉你”CI 挂了”，而是要求”解释根因 + 附上修复”。这其实是把 CI 失败当作一种沟通机制，而不是简单的 pass/fail。

4. IDE 友好 — 明确提到了 AI 编码工具的集成方式，说明这个 skill 是为现代 AI 辅助开发流程设计的。

🤔 不足#

1. 内容偏少 — 相比其他 skill，这个 skill 只定义了规则框架，缺少具体的 CI 配置文件模板（GitHub Actions、GitLab CI、Jenkins 等），实战时需要自己补充。

2. 缺少回滚策略 — 定义了”如何发布”，但没有定义”发布失败怎么回滚”，这是 CI/CD 合规中另一个重要环节。

3. 没有安全扫描门禁 — 现代 CI/CD 管道通常包含 SAST/DAST/依赖扫描等安全门禁，这里没有涉及。

第一步：在你的仓库中定义门禁#

根据你的技术栈，将 CI Gates 序列映射到具体工具。例如前端项目：

1
# 简化版 GitHub Actions 示例
2
jobs:
3
  install:
4
    runs-on: ubuntu-latest
5
    steps:
6
      - uses: actions/checkout@v4
7
      - uses: pnpm/action-setup@v4
8
      - run: pnpm install --frozen-lockfile
9

10
  lint:
11
    needs: install
12
    runs-on: ubuntu-latest
13
    steps:
14
      - uses: actions/checkout@v4
15
      - uses: pnpm/action-setup@v4
16
      - run: pnpm lint
17

18
  typecheck:
19
    needs: install
20
    runs-on: ubuntu-latest
21
    steps:
22
      - run: pnpm typecheck
23

24
  test:
25
    needs: install
26
    runs-on: ubuntu-latest
27
    steps:
28
      - run: pnpm test -- --coverage
29

30
  build:
31
    needs: [lint, typecheck, test]
32
    runs-on: ubuntu-latest
33
    steps:
34
      - run: pnpm build

第二步：配置合并策略#

在 GitHub 的 Branch Protection Rules 中：

• ✅ 要求状态检查通过（Require status checks to pass before merging）
• ✅ 选择上面定义的所有 CI job 为必需检查
• ✅ 启用”Require branches to be up to date before merging”

第三步：设置自动部署#

1
# 合并到 main 后自动部署到 staging
2
deploy-staging:
3
  needs: build
4
  if: github.ref == 'refs/heads/main'
5
  runs-on: ubuntu-latest
6
  steps:
7
    - run: ./deploy.sh staging
8

9
# 生产环境需要手动审批或 tag
10
deploy-production:
11
  needs: build
12
  if: startsWith(github.ref, 'refs/tags/v')
13
  runs-on: ubuntu-latest
14
  environment: production  # GitHub Environment 可配置审批
15
  steps:
16
    - run: ./deploy.sh production

第四步：失败处理自动化#

利用 GitHub 的 PR 评论 bot 或自定义 action，在 CI 失败时自动在 PR 中评论：

1
❌ CI 失败：typecheck 未通过
2

3
根因：src/api/user.ts:42 - 类型不匹配，期望 `UserResponse` 但收到 `UserResponse[]`
4

5
修复建议：将 `const user: UserResponse = await api.get('/user')`
6
改为 `const user: UserResponse[] = await api.get('/users')`
7
或调整 API 返回值类型定义。