📚 课程目录第3章 CI分层支持概述

3. CI分层支持概述：分层测试的思想，CI流水线中如何分层

聊灰度验证之前，得先把CI流水线里的分层逻辑讲清楚。我个人的经验是，很多人一上来就想搞端到端自动化，结果流水线跑一次要两小时，还老失败。说白了，就是没搞明白「分层」这个基本思想。

分层测试的核心就一句话：用最少的成本，最快地发现最多的问题。你想想看，如果每个代码提交都跑全量回归，那谁都受不了。所以我们要把测试按范围、按速度、按可信度拆成几层，每层负责不同粒度的问题。

3.1 三层模型：从微观到宏观

我在实践中通常把CI流水线里的测试分成三个层次。这个模型不是我自己瞎编的，Google、微软那些大厂内部也是这么搞的，只不过叫法不同罢了。

层次	名称	典型工具	执行时间	关注点
L1	单元测试 + 静态分析	Jest, JUnit, ESLint, SonarQube	秒级～分钟级	单个函数/模块的正确性、代码规范
L2	服务/接口测试 + 契约测试	Postman, Pact, REST Assured	分钟级～10分钟	模块间交互、API一致性
L3	集成/E2E测试 + 灰度验证	Cypress, Playwright, K6, Argo Rollouts	10分钟～小时级	用户场景、多服务协同、生产环境行为

关键原则：每一层发现的问题，原则上不应该留到下一层。L1能拦截的bug，绝不让它流到L2；L2能抓到的接口问题，别拖到L3才爆出来。

我曾经见过一个团队，L1只跑单元测试，忽略静态分析。结果上线前SonarQube扫出200多个严重代码异味，临时改代码改到崩溃。现在我每个项目都会在L1里强制加上lint和代码扫描。

3.2 流水线中的分层落地姿势

光有理论不行，得看CI流水线里怎么配。我最常用的方式是把流水线拆成三个阶段，每个阶段对应一个测试层次。

# 以GitLab CI为例，一个典型的分层流水线片段
stages:
  - lint-and-unit
  - integration
  - e2e-and-progressive

lint-and-unit:
  stage: lint-and-unit
  script:
    - npm run lint
    - npm run test:unit
  only:
    - merge_requests

integration:
  stage: integration
  script:
    - docker-compose up -d
    - npm run test:integration
  needs: ["lint-and-unit"]
  only:
    - merge_requests

e2e-and-progressive:
  stage: e2e-and-progressive
  script:
    - npm run test:e2e
    - ./scripts/canary-deploy.sh
  needs: ["integration"]
  when: manual  # 非阻塞，可手动触发灰度
  only:
    - main

注意几个细节：

L1是强制通过的：如果不通过，MR不允许合并。这叫「门禁」。
L2也是强制：但它的耗时决定了开发体验。如果L2跑太久，我会考虑并行化。
L3是可选/手动触发：因为E2E和灰度验证成本高，没必要每次commit都跑。我个人习惯只在合并到主干、或者推送release标签时才触发。

3.3 为什么灰度验证放在最顶层？

灰度验证本质上是把新版本暴露给一小部分真实流量，观察行为。这和前两层有本质区别：前两层是在隔离环境里验证「功能对不对」，灰度验证是在生产环境里验证「行为稳不稳」。

所以它的位置天然就应该在流水线的最顶层——等所有自动化测试都过了，再把版本推到一个灰度池里。举个例子：

L1单元测试跑完，发现一个函数边界条件处理错了，修复后重新提交。
L2接口测试通过，确认新老API兼容。
L3灰度验证开始：先放给2%的测试用户，观察10分钟。如果错误率上升，自动回滚。

这中间有一个重要的概念叫「测试金字塔在CI中的变形」。传统测试金字塔是上窄下宽，但CI流水线里为了速度，往往把L1和L2做得很厚，L3只是作为「保险」存在。我在一个电商项目中就遇到过，L3灰度阶段捕获了一个只在生产环境触发的数据竞态问题，L2死活复现不了——这就是分层的好处：不同层负责不同维度。

别踩的坑：不要把L2的覆盖度做得太薄，然后把所有希望寄托在L3灰度上。灰度验证再牛，也不能替代接口层的语义检查。我曾经见过一个团队，L2只测了HTTP 200，结果微服务之间的JSON字段类型变了，灰度用户直接看到页面白屏——因为L2根本没做schema校验。

3.4 分层与灰度验证的协作模型

下面这张图是我自己画的分层协作关系，你可以把它理解成CI流水线的「交通指挥」。每一层都是一个检查点，灰度验证是最后一道关卡，同时也是反馈回路。

3.5 分层不光是测试，还涉及基础设施

你可能注意到了，上面的流水线配置里，L3用了when: manual。为什么？因为灰度验证需要额外的基础设施支持：

流量控制能力：比如服务网格、网关的路由规则。
监控和告警：能实时看到错误率、延迟变化。
自动回滚：检测到异常后，能自动把流量切回老版本。

这些不是CI工具本身提供的，而是需要平台团队提前搭好。我记得有一次帮客户做灰度改造，CI流水线里的分层是画清楚了，结果运维说「我们没有灰度网关」……所以，落地之前一定要先盘点基础设施。

落地检查清单：

✅ L1 门禁是否强制？MR未通过能合入吗？
✅ L2 契约测试是否覆盖了所有外部依赖？
✅ 灰度环境是否有独立的监控面板？
✅ 回滚按钮或自动回滚是否就绪？

3.6 小结：分层就是「分而治之」

其实说到底，CI分层支持不是什么新鲜概念。它就是把大型测试集拆成可管理的块，每块有明确的职责和退出标准。灰度验证放顶层，因为它最接近生产，也最贵。但贵不代表不用，而是要用在刀刃上。

我个人最喜欢的比喻是：L1是安检，L2是海关，L3是目的地警察。每一层都有权拦下可疑的人，但只有到了目的地，你才知道行李里是不是真的没问题。灰度验证，就是那个「到了目的地之后」的最终检查。