CI／CD自动化回归测试与质量门禁建设 - 第1节

CI/CD 到底是什么？先搞清楚这三个概念

先问个问题：你每次提交代码之后，是不是还得手动编译、跑测试、再部署？我以前就是这样干的，结果呢？某次凌晨上线，手抖点错了环境，把测试库当成生产库给覆盖了……嗯，从那天起，我下定决心要搞明白 CI/CD。

其实 CI/CD 这个词已经被说烂了，但很多人分不清三个字母分别代表什么。尤其是两个 CD——持续交付（Continuous Delivery）和持续部署（Continuous Deployment），经常被混用。今天咱们就把它掰开揉碎了讲清楚。

持续集成（Continuous Integration，CI）

说白了，就是让开发者频繁地把代码合并到主干。我以前带过一个团队，大家各写各的，快上线了才合代码，结果冲突大到改了两天——从那以后我强制要求每天至少合并一次。CI 的核心是：每次合并都自动触发构建和测试。

持续交付（Continuous Delivery）

我把它理解为「代码始终处于可部署状态」。你想想看，CI 只是保证代码能编译通过、测试通过，但持续交付还要把构建好的产物放到一个类似预发布环境的地方，让人随时可以手动点击「部署到生产」。我在一个金融项目里就是这么做的：所有测试通过后，自动打包成 Docker 镜像并推送到仓库，运维拿着镜像就可以一键发布。

持续部署（Continuous Deployment）

这个就狠了——连「手动点击」这一步都省了。只要代码通过所有自动化测试，系统直接部署到生产环境。我曾经在内部工具项目里试过这种方式，结果有一次因为测试环境配置漏了个参数，新版本直接推到了线上……所以我不建议新手一开始就上持续部署，至少要把回归测试做扎实了再说。

三种概念对比

维度	持续集成（CI）	持续交付（CD）	持续部署（CD）
目标	尽早发现集成问题	代码随时可上线	变更自动上线
部署方式	不涉及部署	手动到生产	自动到生产
测试覆盖	单元+集成测试	+验收测试	+全量回归
风险等级	低	中	高

回归自动化在 CI/CD 中的位置

你可能要问：这三兄弟和回归测试有什么关系？关系大了去了。没有回归自动化，CI/CD 就像没有安全带的过山车。

CI 阶段的回归自动化

每次代码提交，自动跑一遍单元测试和集成测试。我习惯在 CI 脚本里把回归测试按优先级分三层：第一层是核心业务的冒烟测试（5 分钟内跑完），第二层是全量单元测试（10 分钟），第三层是端到端回归（独立流水线，异步跑）。

# 一个简单的.gitlab-ci.yml片段
stages:
  - build
  - test

regression_smoke:
  stage: test
  script:
    - npm test -- --grep "smoke"  # 只跑冒烟用例
  only:
    - merge_requests

regression_full:
  stage: test
  script:
    - npm run test:full          # 全量回归
  when: manual                   # 人工按需触发

CD 阶段的回归自动化

持续交付阶段，回归测试是对整个发布包的「临门一脚」。我记得有一次在预发布环境跑回归时发现了一个数据库连接池泄露的问题，幸亏被自动化用例揪出来了——不然上线后半小时所有 API 都会超时。

一张图看懂 CI/CD 与回归自动化的关系

为什么回归自动化是 CI/CD 的压舱石？

没有回归测试的 CI/CD 就是「跑得快、死得也快」。你想想看，代码每天合并几十次，如果没有自动化回归，你靠人工一个个点？我见过最惨的案例是：一个大项目上线前才发现一个老功能被新代码改坏了，因为那行代码三个月没人动过，谁也没想到会出问题。

回归自动化的三个层次

1. 代码级回归：单元测试+静态分析。每次提交都跑，杜绝低级错误。
2. 接口级回归：API 测试+契约测试。我在微服务项目里重点搞这个，因为服务之间的接口变了很难察觉。
3. 用户场景级回归：UI 自动化+端到端测试。这个跑得慢，所以我会放在夜间或者按需触发。

小结：弄清楚概念，后面才走不歪

CI 解决的是「能不能合到一起」，CD 解决的是「能不能放出去」。回归自动化就是连接这两个「能」的保险丝。我个人习惯把回归测试分成快慢两条跑道：快的跑在 CI 里，慢的跑在 CD 前。

记住一句话：持续集成的频率决定了你能多快发现 bug，回归自动化的质量决定了你发现 bug 后敢不敢继续改。