CI/CD 基础概念：持续集成、持续交付、持续部署的定义与区别
聊到 CI/CD，很多刚接触座舱开发的同学容易搞混。我刚开始带项目时也犯过这个错——以为只要搭了个 Jenkins 跑自动化编译，就算上了 CI/CD。结果呢？代码集成没问题，但交付流程还是一团乱麻。
说白了，CI/CD 不是单一工具，而是一套方法论。它包含三个核心环节：持续集成、持续交付、持续部署。每个环节解决不同的问题，但环环相扣。
一句话总结：持续集成解决「能不能合到一起」；持续交付解决「能不能随时发版」；持续部署解决「能不能自动上线」。
持续集成（Continuous Integration）
持续集成，简称 CI。它的核心动作是：频繁地把代码合并到主干，并自动验证。
我见过太多团队，开发两周才合一次代码。结果合并时冲突几百个，修完冲突编译又挂，编译过了测试又崩。整个团队花两三天「稳定代码」，效率极低。
CI 的做法正好相反——每天合并多次，每次合并都触发自动化构建和测试。一旦失败，立刻通知开发者修复。
我的经验：座舱项目里，CI 至少要跑三层检查——编译检查、静态代码扫描、单元测试。这三层跑通，代码才能合入主干。我曾经在某个项目中漏了静态扫描，结果合入的代码带了内存泄漏，上线后偶发黑屏，排查了整整两天。
CI 的关键要素：
- 频繁提交：每天至少提交一次代码到主干
- 自动化构建：提交后自动编译、打包
- 自动化测试：单元测试、接口测试自动执行
- 快速反馈：构建失败在 10 分钟内通知到人
持续交付（Continuous Delivery）
持续交付是 CI 的下一站。它保证：代码任何时候都处于可发布状态。
你想想看，CI 只保证代码能编译、能通过单元测试。但能不能部署到真车上跑？能不能通过全量回归测试？这些是持续交付要解决的问题。
我习惯把持续交付理解为「一键发布就绪」。每次代码合入主干后，自动化流水线会完成：
- 全量编译（Release 模式）
- 集成测试（HIL/台架测试）
- 性能测试（启动时间、帧率、内存）
- 生成发布包（带版本号、签名）
这些步骤全部通过后，这个版本就「可交付」了。要不要真正上线，由业务决定。
注意：持续交付不等于持续部署。交付是「准备好了」，部署是「真的上了」。很多座舱项目只做到持续交付——因为上线需要走审批流程、需要灰度验证、需要和云端服务对齐版本。
持续部署（Continuous Deployment）
持续部署是 CI/CD 的终极形态。它把「上线」这一步也自动化了。
代码合入主干 → 自动构建 → 自动测试 → 自动部署到生产环境。整个过程没有人工干预。
说实话，在座舱领域做到持续部署的团队不多。为什么？因为车机系统升级风险太高——一旦推送了有问题的版本，用户可能面临黑屏、卡死、功能失效。这不是 Web 应用能回滚就完事的。
我参与过的一个项目，尝试过 OTA 持续部署。我们做了三层防护：
- 灰度发布：先推 1% 的车，观察 24 小时
- 自动回滚：如果异常指标超过阈值，自动触发回滚
- 人工确认门禁：灰度通过后，需要架构师确认才能全量推送
即便如此，还是出过一次问题——某个车型的 MCU 固件兼容性没覆盖到，导致 200 台车空调控制失效。嗯，从那以后我们加了一条规则：持续部署必须包含全车型兼容性矩阵测试。
三者的区别与联系
用一个表格来对比，会更清楚：
| 维度 | 持续集成（CI） | 持续交付（CD） | 持续部署（CD） |
|---|---|---|---|
| 核心目标 | 代码合并后不坏 | 代码随时可发布 | 代码自动上线 |
| 自动化范围 | 编译 + 单元测试 | 编译 + 全量测试 + 打包 | 编译 + 测试 + 部署 |
| 人工介入 | 无（自动触发） | 有（审批后发布） | 无（全自动） |
| 适用场景 | 所有项目 | 大部分座舱项目 | 成熟团队 + 强自动化 |
| 风险等级 | 低 | 中 | 高 |
它们的关系可以用一张图来展示：
座舱项目中的实践建议
结合我这些年的经验，给几个实操建议：
- 从 CI 起步：别一上来就搞全自动部署。先把编译和单元测试自动化跑通，这是最基础也是回报最高的。
- 持续交付是底线：座舱项目迭代快，两周一个版本是常态。如果做不到随时可发布，每次发版都会手忙脚乱。
- 持续部署要谨慎：除非你的自动化测试覆盖率达到 90% 以上，且有完善的灰度机制，否则别轻易上持续部署。
一个小技巧：我习惯在 CI 流水线里加一个「构建耗时趋势图」。如果某次构建时间突然翻倍，大概率是有人引入了冗余依赖或者测试用例写得有问题。这个指标比代码 review 更能暴露问题。
最后说一句：CI/CD 不是银弹。它解决的是「集成和交付的效率问题」，解决不了「代码质量差」和「架构设计烂」的问题。先把代码写清楚，再把流程自动化，顺序别搞反了。