4、持续集成（CI）流水线：CI触发策略、代码检查与单元测试、构建产物生成、CI报告与通知

好，咱们进入CI流水线这个核心环节。

说实话，很多团队把CI理解成「只要代码能编译通过就行」。这其实是个误区。我见过太多项目，CI跑得挺欢，但每次发布前还是手忙脚乱。为什么？因为CI流水线没有真正把「质量门禁」立起来。

今天咱们就掰开揉碎，把CI流水线的四个关键环节讲透：触发策略、代码检查与单元测试、构建产物生成、报告与通知。

4.1 CI触发策略：别让流水线白跑

触发策略，说白了就是「什么时候该跑CI」。我个人的习惯是：能早触发就别晚触发，能细粒度就别粗放。

常见的触发方式有这几种：

Push触发：每次提交代码到远程仓库，立即触发。适合小团队、快速迭代。
PR/MR触发：创建或更新合并请求时触发。这是企业级项目的标配。
定时触发：比如每天凌晨跑一次全量测试。适合做回归验证。
手动触发：用于特殊场景，比如紧急修复时跳过某些检查。

这里有个坑，我曾经踩过：

我曾经在一个项目中，把所有分支的push都配置了全量CI。结果开发同学一天提交几十次，CI排队排到天荒地老。后来我改成：只有main和release分支做全量CI，feature分支只做增量检查。效率直接翻倍。

我建议你采用「分层触发」策略：

分支类型	触发事件	执行内容
feature/*	Push	代码检查 + 单元测试（增量）
PR到main	PR创建/更新	全量代码检查 + 单元测试 + 构建
main	Push	全量检查 + 测试 + 构建 + 产物归档
release/*	Push	全量流程 + 签名 + 发布

你想想看，这样设计后，开发同学在feature分支上改代码，几秒钟就能拿到检查结果。而合并到main时，才会跑完整的「质量门禁」。既保证了速度，又守住了质量。

4.2 代码检查与单元测试：把问题扼杀在摇篮里

代码检查和单元测试，是CI流水线的「守门员」。我见过太多SDK发布后，用户反馈「编译报错」「API调用崩溃」。其实这些问题，在CI阶段完全可以拦截。

4.2.1 代码检查：不止是格式化

代码检查分两层：

静态分析：检查代码风格、潜在bug、安全漏洞。比如ESLint、Pylint、Checkstyle。
类型检查：TypeScript的tsc、Python的mypy。这步很多人忽略，但特别重要。

我记得有一次，团队里一个同学在SDK里写了个函数，参数类型写错了。因为没做类型检查，编译通过了，但运行时直接崩溃。用户反馈过来，我们排查了半天。从那以后，我把类型检查加到了CI的强制步骤里。

核心原则：代码检查失败，CI直接红牌。不允许合并，不允许发布。

一个典型的代码检查配置示例：

# .github/workflows/ci.yml 片段
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: 安装依赖
        run: npm ci
      - name: ESLint检查
        run: npx eslint src/ --max-warnings=0
      - name: 类型检查
        run: npx tsc --noEmit

4.2.2 单元测试：覆盖率不是唯一指标

单元测试这块，很多团队只盯着覆盖率。其实，测试的质量比覆盖率重要得多。

我个人的习惯是：

核心API的单元测试覆盖率必须达到90%以上
边界条件测试（空值、异常输入、并发场景）必须覆盖
每个public方法至少有一个正向用例和一个异常用例

举个例子，SDK里有个「用户登录」的API：

// 不好的测试：只测了正常登录
test('登录成功', () => {
  expect(login('valid_user', 'valid_pass')).toBe(true);
});

// 好的测试：覆盖了各种边界
test('登录成功', () => {
  expect(login('valid_user', 'valid_pass')).toBe(true);
});

test('密码错误', () => {
  expect(login('valid_user', 'wrong_pass')).toBe(false);
});

test('用户名为空', () => {
  expect(() => login('', 'pass')).toThrow('用户名不能为空');
});

test('并发登录', async () => {
  const results = await Promise.all([
    login('user1', 'pass1'),
    login('user1', 'pass1'),
  ]);
  expect(results).toEqual([true, true]);
});

小技巧：在CI中配置「测试失败自动重试一次」。因为有些测试是偶发性的（比如网络超时），重试一次能减少误报。但注意，重试次数不要超过2次，否则会掩盖真正的问题。

4.3 构建产物生成：从源码到可交付物

构建产物，就是SDK最终交付给用户的东西。可能是npm包、jar包、Docker镜像，或者一个压缩包。

这里有个关键点：构建过程必须可重复、可追溯。

我建议你这样做：

锁定依赖版本：使用lock文件（package-lock.json、poetry.lock等），确保每次构建的依赖完全一致。
构建环境标准化：用Docker容器来跑构建，避免「在我机器上能跑」的问题。
产物签名：对构建产物进行哈希签名（SHA256），用户下载后可以验证完整性。

一个典型的构建产物生成流程：

# 构建阶段
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: 设置Node版本
        uses: actions/setup-node@v3
        with:
          node-version: '18'
          cache: 'npm'
      - name: 安装依赖
        run: npm ci
      - name: 构建SDK
        run: npm run build
      - name: 生成签名
        run: |
          sha256sum dist/*.js > dist/checksums.sha256
      - name: 上传产物
        uses: actions/upload-artifact@v3
        with:
          name: sdk-artifact
          path: dist/

嗯，这里要注意：构建产物不要包含源码中的敏感信息。比如API密钥、数据库连接串。我曾经见过一个SDK，构建时把.env文件打包进去了，结果用户反编译后直接拿到了生产环境的密钥。这是个非常严重的教训。

4.4 CI报告与通知：让结果触达每个人

CI跑完了，结果怎么让团队知道？我见过最原始的方式：开发同学自己点开CI页面看。这显然不行。

好的通知机制应该是：

即时通知：CI失败时，立即通知提交者。用Slack、钉钉、邮件都行。
汇总报告：每天/每周生成一份CI质量报告，包括通过率、失败原因、趋势分析。
可视化看板：在团队内部展示CI状态看板，让每个人一眼看到当前质量状况。

我习惯在CI流水线的最后一步，生成一份HTML格式的报告：

# 生成CI报告
- name: 生成CI报告
  run: |
    cat << EOF > ci-report.html
    <html>
    <body>
    <h2>SDK CI 报告</h2>
    <p>提交者: ${{ github.actor }}</p>
    <p>分支: ${{ github.ref }}</p>
    <p>代码检查: ✅ 通过</p>
    <p>单元测试: 98% 通过 (失败: 2/100)</p>
    <p>构建产物: sdk-v1.2.3.zip</p>
    <p>签名: a1b2c3d4...</p>
    </body>
    </html>
    EOF

通知的黄金法则：失败通知要「吵」一点，成功通知要「静」一点。CI失败时，最好能@到具体的人。CI成功时，一条静默通知就够了。

4.5 本章核心逻辑图

下面这张图，把CI流水线的四个环节串起来了。你可以看到，从代码提交到最终通知，每一步都有明确的输入和输出。

这张图里，我特意把「检查通过？」这个决策点画了出来。你想想看，如果检查不通过，后面的构建和归档根本不会执行。这就是「质量门禁」的威力。

我的经验：刚开始搭建CI流水线时，不要追求一步到位。先跑通核心流程（触发→检查→构建→通知），然后再逐步加入代码覆盖率、安全扫描、性能测试等高级功能。迭代优化，比一次性搞个大而全的方案要靠谱得多。

好了，CI流水线的核心内容就这些。记住一句话：CI不是跑个脚本就完事，它是你SDK质量的最后一道防线。把触发策略、代码检查、构建产物、报告通知这四个环节做扎实了，你的SDK发布流程就成功了一半。

可可精品资料库

📚 课程目录

4、持续集成（CI）流水线：CI触发策略、代码检查与单元测试、构建产物生成、CI报告与通知

4.1 CI触发策略：别让流水线白跑

4.2 代码检查与单元测试：把问题扼杀在摇篮里

4.2.1 代码检查：不止是格式化

4.2.2 单元测试：覆盖率不是唯一指标

4.3 构建产物生成：从源码到可交付物

4.4 CI报告与通知：让结果触达每个人

4.5 本章核心逻辑图