质控流程基础
聊到CI/CD流程的稳定性，很多人第一反应就是“多写测试用例”。
但说实话，我见过不少团队，测试用例写了一大堆，流水线却照样频繁崩溃。问题出在哪？
出在缺少一套靠谱的质量控制流程。也就是我们常说的质控流程。
质量控制的定义
质量控制，英文叫Quality Control，简称QC。
它不是什么高大上的理论。说白了，就是在软件交付的每个关键节点，设置检查点，确保产出物符合预期标准。
我个人的理解是：质控流程像是一条流水线上的质检员。零件经过一道工序，质检员就要看一眼，有没有毛刺，尺寸对不对。不对的，直接打回去返工。
在CI/CD里，这个“质检员”就是自动化脚本和工具链的集合。
质控的核心动作只有三件事：
- 检查：验证产出物是否满足预设条件
- 阻断：不合格的产出物不允许流入下一环节
- 反馈：把检查结果及时通知给相关人
举个例子，代码提交后触发构建。构建完成后，我们做两件事：
- 检查编译是否通过
- 检查单元测试覆盖率是否达标
只要有一条不满足，流水线就直接中断。这就是一次完整的质控动作。
质控流程的目标
你可能要问，费这么大劲搞质控，到底图什么？
目标很明确，就三个字：稳、快、准。
| 目标 | 解释 | 我踩过的坑 |
|---|---|---|
| 稳 | 流水线每次运行，结果一致。不会这次绿、下次红 | 曾经有个项目，测试依赖网络环境，办公室网一卡，流水线就挂。后来我强制所有测试用Mock数据 |
| 快 | 尽早发现问题，缩短反馈周期。最好提交代码后几分钟内就出结果 | 我记得有个后端团队，全量测试跑一次要40分钟。我建议他们把代码检查和单元测试拆出来，先跑快的 |
| 准 | 失败的原因要明确。不能报了错，开发还得猜半天 | 我之前见过一个流水线，报错信息只有“Exit code 1”。开发看到想骂人。后来我们统一规范了日志格式 |
这三个目标缺一不可。流水线跑得很快，但经常随机失败，那叫“假快”。指标很稳定，但跑一次要两小时，那叫“慢而稳”。都不行。
与测试空间的关系
质控流程和测试空间是强绑定的关系。你想想看，没有测试空间，质控流程要检查谁？反过来，没有质控流程，测试空间里的测试跑完，谁来判断结果合不合格？
它们之间的关系，我习惯用一张图来表示：
你看这张图，左侧是测试空间，负责执行各种类型的测试。右侧是质控流程，负责定义标准和做决策。
它们之间有两股流动：
- 数据流：测试空间把测试结果、覆盖率、执行日志等数据，喂给质控流程
- 指令流：质控流程根据数据做出判断，向下游发出“通过”或“阻断”的指令
我建议的落地策略：
不要把质控逻辑硬编码在流水线脚本里。把它独立成一个服务或模块。
比如我们团队的做法：
# 在流水线配置中只调用质控服务
- stage: quality_gate
script:
- curl -X POST http://qc-service/check \
-d '{"pipeline_id": "$CI_PIPELINE_ID"}'
- if [ $? -ne 0 ]; then exit 1; fi这样质控规则变了，只需要改质控服务，不用动每条流水线。
质控流程的核心原则
有了目标和关系，我们还得守住几条原则。不然很容易跑偏。
- 尽早发现，尽早阻断。问题暴露得越晚，修它的成本就越高。我个人习惯在代码提交后的第一个环节就做最轻量的检查，比如代码风格和静态分析。
- 规则要透明，不要有黑箱。质控流程里每一条规则，开发团队都应该知道。我曾经遇到过一个项目，测试不通过的代码不会被合并，但没人知道具体标准是什么。搞得大家天天猜。
- 持续改进，拒绝僵化。质控流程不是写一次就完事的。它要随着项目演进不断调整。我建议每个迭代结束后，花半小时复盘一下：哪些质控点误报太多？哪些漏报严重？然后更新规则。
特别提醒：
质控流程不是越多越好。每加一个检查点，流水线就多一层开销。
我曾经接手过一个项目，流水线里堆了30多个检查节点。结果80%的失败都是同一个lint规则导致的。其他节点全是噪音。
所以我的原则是：每个检查点要有明确的价值，没有价值的，坚决砍掉。
本章小结
质控流程是CI/CD流水线稳定性的基石。它不是什么锦上添花的东西。
- 它的定义：在交付节点做检查、阻断、反馈。
- 它的目标：稳、快、准。
- 它与测试空间：数据流+指令流的双向关系。
- 它的原则：尽早、透明、持续改进。
嗯，把这些搞清楚了，后面搭建具体的质控工具和规则时，才不会跑偏。