4. CI/CD 基础概念:持续集成、持续交付、持续部署

CI/CD 是什么?说白了,它是一套自动化的「流水线」。咱们证书接口回归测试想要跑得又快又稳,没有这套流水线是根本行不通的。我最早接触的时候也觉得不就是个自动构建么?后来才明白,CI/CD 的核心价值在于「快反馈」和「零手动」。今天就跟你掰扯清楚这三个概念到底分别指什么。

一句话总结:
持续集成(CI)保证代码合入后不崩;
持续交付(CD)保证代码随时可部署;
持续部署(CD)保证代码自动部署上线。

4.1 持续集成(Continuous Integration)

持续集成,简单来说就是「频繁地把代码合并到主干,然后自动构建和测试」。我个人习惯每天至少合并一次代码,而不是攒一个礼拜再合。你想想看,如果两周才合一次,出了冲突要解决半天,修复起来脑袋疼。我曾经在一个项目里,团队成员各自开发两周,合并时直接花了三天解决冲突,从那以后我就铁了心推行 CI。

CI 的核心流程包括:

  • 开发者提交代码到共享仓库(比如 Git)
  • 触发自动构建(编译、打包)
  • 自动运行单元测试 & 回归测试
  • 提供测试报告,如果失败了立刻通知负责人

举个例子,证书接口测试的 CI 流程可以这么配:

# .gitlab-ci.yml 示例
stages:
  - build
  - test

build-job:
  stage: build
  script:
    - mvn clean package -DskipTests

test-job:
  stage: test
  script:
    - mvn test
    - mvn verify
  artifacts:
    reports:
      junit: target/surefire-reports/*.xml
小建议: CI 失败后,不要手动去服务器上调试。直接在本地重跑一遍流水线,暴露问题更快。我一般在流水线里加一个「快速失败」机制,一旦单元测试红,后续步骤直接跳过。

4.2 持续交付(Continuous Delivery)

持续交付是说:代码通过 CI 后,自动部署到 Staging 环境,并通过验收测试,确保它「生产就绪」。但注意,它不会自己上线,需要人工点击确认。

我曾经在交付环节吃过亏。有次 CI 全绿,我们直接把产物放到 Staging 环境,结果证书签名算法的兼容性测试在 Staging 才暴露出来——因为生产环境的证书链和 Staging 不一样。如果你只依赖 CI 的单元测试,是不够的。持续交付强调的就是:每次提交的产物都值得被部署,它的质量必须经过 Staging 环境的验证。

为什么要有交付这一步?因为实际生产环境的网络、配置、证书库跟 CI 环境差别很大。在交付环节把验证做扎实,你的「确认上线」按钮才敢于按下去。

环节 谁触发 验证内容
持续集成(CI) 每次提交 编译、单元测试、集成测试
持续交付(CD-delivery) 自动 Staging 环境验收、证书兼容性、回归测试
持续部署(CD-deployment) 自动 生产环境发布、灰度、监控

4.3 持续部署(Continuous Deployment)

持续部署比持续交付更激进:所有通过 CI + Staging 验证的代码,直接自动发布到生产。这个过程不需要任何人工审批。你们肯定有人会问:那不上线风险很高吗?没错,所以持续部署对测试覆盖率、蓝绿部署、灰度发布、回滚机制要求非常高。

举个证书接口的场景:如果你的证书过期监测、双向认证、撤销列表校验等接口在 CI 和 Staging 都通过了,持续部署可以把它们推到一个很小的灰度分组(比如1%流量),确认无误后再全量推。我见过最快的流程:提交代码到生产环境只用了 12 分钟,而其中 10 分钟在跑测试,2 分钟在部署。

避坑指南: 我曾经在一个项目里盲目上持续部署,结果证书根 CA 变更后,线上旧证书还没全部替换,新代码直接部署导致部分客户端握手失败。因为部署时没有做「多版本证书兼容测试」。从那以后,我要求证书接口的流水线必须包含「新旧证书并行验证」步骤。

4.4 CI/CD 流水线的整体关系

这三者不是三个独立的工具,而是一套完整的流程。我把它们的关系画成一张图,你看完会更清晰:

CI/CD 持续交付流程与价值分层 持续集成 (CI) 代码合并 → 构建 → 单元测试 快速发现编译与集成问题 持续交付 (CD) Staging 部署 → 验收测试 确保产物「生产就绪」 持续部署 (CD) 灰度发布 → 全量部署 自动推送到生产环境 自动 自动 价值分层:越往右自动化程度越高,运行频率越低 CI 解决「合不进去」;交付解决「能不能上线」;部署解决「怎么安全上线」 证书接口回归测试在 CI 做集成验证,在交付做权限/兼容性验收,在部署做灰度 证书接口示例流水线 提交代码 → CI 编译 & 单元测试 + 接口回归测试 → CD 部署至 Staging(验证证书链与签名算法) → CD 部署至生产(先 1% 灰度,观察 10 分钟自动全量)

4.5 站在证书回归测试角度看 CI/CD

回到咱们的课程内容:证书接口回归测试如何与 CI/CD 集成?我建议你们把回归测试脚本放在 CI 阶段,把证书有效性验证放在 CD 阶段。CI 保证代码没破坏接口,CD 保证在真实环境中证书能握手。

  • CI 阶段:每次提交自动运行单元测试 + 证书接口回归集,失败的用例直接阻断流水线。
  • CD 交付阶段:自动部署到 Staging 环境,运行全套证书集成测试(包括过期证书、自签名、根 CA 变更等场景)。
  • CD 部署阶段:灰度推送,同时监听证书错误率,一旦上升立刻回滚。
实用配置要点:
CI 阶段不应依赖生产环境证书库,应该用 Mock 或测试 CA。
交付阶段必须使用与生产环境一致的证书库副本。
部署阶段需要从基础设施层保证回滚时证书也一起回滚。

我见过很多人把 CI 和 CD 混为一谈,认为跑通测试就算是部署了。其实不是,CI 只是第一步。要想让证书接口的回归测试真正产生价值,你需要把这三层都打通。后面我会继续拆解每一层里具体的工具和配置方法,今天你先把这个概念刻在脑子里。

核心记忆点: CI 测「对不对」,交付测「能不能用」,部署管「如何安全地让用户用」。每一层都有它的职责,少一层你的证书接口就可能在线上翻车。