3. CI/CD基础

在OTA测试与发布工程中，CI/CD不是“顺带做一下”的辅助能力，而是把代码变更稳定、可重复、可追溯地送到车端或终端设备的基础设施。理解持续集成（Continuous Integration，CI）、持续交付（Continuous Delivery，CD）与持续部署（Continuous Deployment，CD）三者的边界，是设计流水线、划分质量门禁和确定发布策略的前提。

一、三个概念的定义与边界

持续集成强调开发者频繁地把代码合入主干，每次合入都自动触发构建、静态检查与自动化测试，尽早暴露集成缺陷。它的核心产物是“可验证的构建物”和“可信的测试结果”。

持续交付是在持续集成基础上，保证软件在任何时刻都处于“可发布”状态：构建物经过完整测试、版本标记、制品归档后，可以一键部署到类生产环境，但最终是否发布到用户侧由人工决策。它解决的是“发布准备度”问题。

持续部署则把人工审批也去掉，只要通过全部质量门禁，构建物就自动发布到生产环境。它要求极高的自动化测试覆盖、灰度能力与回滚能力，在OTA场景中通常表现为“自动推送到灰度批次”，而非直接全量推送。

二、CI/CD的核心价值

• 缩短反馈周期：从提交到拿到测试结果的时间从数天缩短到分钟级，缺陷修复成本显著下降。
• 降低集成风险：小批量、高频次的合并避免了“集成地狱”，冲突和回归问题更早暴露。
• 提升发布可信度：每次发布都经过同一套流水线，构建物可追溯、可复现，减少“在我机器上是好的”问题。
• 支撑OTA灰度与回滚：标准化的制品和版本元数据，使灰度分批、暂停、回滚成为可编排动作。
• 释放工程效率：把重复的构建、刷写、测试、打包工作交给流水线，测试工程师聚焦于用例设计与质量分析。

三、核心原则与流水线阶段

CI/CD的落地依赖几条基本原则：单一可信源（代码与配置统一入库）、构建一次多处部署（同一制品贯穿各环境）、质量门禁前置（快速检查先跑）、环境一致性（容器或镜像固化依赖）、失败即停止（红灯优先修复）。

在OTA测试工程中，一条典型的流水线会经历以下阶段：代码提交触发 → 静态检查与单元测试 → 编译构建与镜像打包 → 制品归档与版本标记 → 部署到台架/仿真环境 → 自动化OTA升级测试 → 生成测试报告与质量门禁 → 人工审批 → 灰度发布 → 全量发布或回滚。

四、工具链概览与选型对照

CI/CD工具链通常由代码托管、流水线编排、构建缓存、制品仓库、测试执行、环境编排、发布与监控几部分组成。不同团队可根据自研程度和合规要求组合使用。

五、典型场景：一次OTA升级包的流水线旅程

假设测试工程师提交了一个修复升级校验逻辑的补丁。流水线首先在CI阶段运行单元测试与静态扫描，确认补丁未破坏基础逻辑；随后构建出带版本号的升级包并推入制品仓库。持续交付阶段，流水线把该包部署到台架环境，自动执行“下载—校验—安装—重启—版本确认”的OTA升级用例，并采集升级耗时、失败码与日志。若全部通过，系统生成测试报告并等待发布负责人审批。审批通过后进入持续部署阶段，升级包先推送到1%的灰度车辆，监控升级成功率与异常上报；指标达标后自动扩大批次，否则触发回滚。

# 流水线关键阶段示例（伪配置）
stages:
  - build        # 编译、单测、静态检查
  - package      # 生成OTA升级包并归档
  - deploy_bench # 部署到台架/仿真环境
  - ota_test     # 自动化升级测试与报告
  - approve      # 人工审批门禁
  - gray_release # 灰度批次推送
  - monitor      # 指标观测与自动回滚

六、常见误区与复盘要点