第二章：CI/CD基础概念
各位同学，今天我们来聊聊CI/CD的基础概念。说实话，这个主题在互联网圈已经讲烂了，但在汽车嵌入式领域，很多人还是一头雾水。我见过不少团队，代码写得不错，但一提到自动化集成就头疼。嗯，咱们今天就把这事掰扯清楚。
2.1 持续集成与持续交付：到底在说什么？
先说说持续集成（CI）。说白了，就是让开发人员频繁地把代码合并到主干。有多频繁？我个人习惯是每天至少一次。你想想看，如果大家各写各的，两周后才合并一次，那场面...我经历过一次，光解决冲突就花了两天。
持续集成要解决的核心问题就一个：让代码始终处于可集成状态。每次提交代码，自动触发构建、跑单元测试、做静态检查。如果红了，谁提交的谁负责修。这个机制一旦跑起来，团队的质量意识会明显提升。
核心要点：
- 频繁合并（每天至少一次）
- 自动化构建与测试
- 快速反馈（提交后15分钟内出结果）
- 失败即阻塞（不允许带病上线）
再来说持续交付（CD）。它是在CI的基础上，让软件随时可以发布到生产环境。注意，是「可以发布」而不是「自动发布」。这个区别很重要。我在项目中遇到过，有些团队把CD理解成自动上线，结果出了事故。其实CD的核心是：让发布变成一个低风险、可重复的标准化操作。
持续部署则是更进一步，代码通过所有测试后自动部署到生产环境。但在汽车行业，这一步我们通常不敢轻易做。为什么？后面会讲。
2.2 Jenkins vs GitLab CI vs GitHub Actions：怎么选？
这三个工具我都深度用过。说实话，没有绝对的好坏，关键看场景。我给大家做个对比，你们自己判断。
| 特性 | Jenkins | GitLab CI | GitHub Actions |
|---|---|---|---|
| 部署方式 | 自托管为主 | 自托管/SaaS | SaaS为主 |
| 配置方式 | Web界面 + Jenkinsfile | .gitlab-ci.yml | .github/workflows/*.yml |
| 插件生态 | 极其丰富（1000+） | 中等 | 丰富（Marketplace） |
| 适合场景 | 复杂流水线、大型项目 | 中小团队、GitLab深度用户 | 开源项目、GitHub用户 |
| 汽车行业适配 | ★★★★★ | ★★★☆☆ | ★★☆☆☆ |
我个人在汽车项目中最常用的是Jenkins。为什么？因为汽车软件开发需要集成大量专用工具，比如Vector的CANoe、DaVinci，还有各种编译器、静态分析工具。Jenkins的插件机制和Pipeline as Code能力，能很好地应对这些复杂场景。
GitLab CI我也用过，在中小型项目中体验不错。它的配置语法简洁，和GitLab仓库集成度高。但遇到需要调用Windows上的Vector工具链时，配置起来就比较折腾了。
GitHub Actions呢？说实话，在汽车行业用得不多。主要是安全合规问题。很多OEM不允许代码托管到公有云，更别说让流水线在别人服务器上跑了。
我的建议：
如果团队规模在10人以下，项目相对独立，可以考虑GitLab CI。如果是大型项目，需要对接多种工具链，Jenkins是更稳妥的选择。至于GitHub Actions，更适合开源项目或原型验证阶段。
2.3 汽车软件中的CI/CD特殊性
好了，重点来了。汽车软件的CI/CD和互联网应用完全不同。我刚开始做汽车项目时，把互联网那套直接搬过来，结果碰了一鼻子灰。这里我总结几个关键差异。
第一，硬件在环测试是刚需。 你写了个CAN通信模块，光做单元测试够吗？不够。必须连上真实的ECU或者至少是HIL（硬件在环）台架才能验证。这就意味着你的CI流水线里，需要预留硬件资源调度。我曾经在Jenkins里写了个插件，专门管理HIL台架的占用和释放，折腾了两个月才稳定。
第二，工具链许可证管理是个大坑。 Vector的工具链，比如CANoe、vTESTstudio，都是按浮动许可证授权的。CI流水线跑起来，同时启动十几个实例，许可证瞬间被占满。其他同事就没法用了。怎么解决？我建议在流水线里加入许可证排队机制，或者设置并发上限。
第三，安全合规要求极高。 汽车软件要满足ASPICE、ISO 26262等标准。这意味着你的CI/CD流水线不仅要跑得快，还要留下完整的审计轨迹。谁在什么时候提交了什么代码？跑了哪些测试？结果如何？这些都要可追溯。我在项目中用Jenkins的Pipeline插件配合Elasticsearch，把所有构建日志和测试报告都存起来，方便审计。
第四，版本管理更复杂。 汽车软件通常涉及多个ECU，每个ECU有自己的软件版本。而且还要和硬件版本、标定数据版本做关联。单纯的Git分支管理已经不够用了。我见过一些团队用Git LFS配合Artifactory来管理二进制文件，效果还不错。
避坑指南：
我曾经在一个项目中，直接把互联网的CI/CD方案照搬过来。结果呢？流水线跑一次要6个小时，因为要编译所有ECU的代码。后来改成增量编译，只编译变更影响的模块，时间降到了40分钟。记住：汽车软件项目，不要追求「全量构建」，要「精准构建」。
第五，测试环境的一致性。 互联网应用可以在Docker里跑测试，环境一致性很好。但汽车软件不行。你没法把ECU塞进Docker容器里。所以测试环境的管理就变得很关键。我建议用虚拟机或者物理机模板来管理测试环境，每次跑流水线前先做环境检查，确保工具链版本、驱动版本都一致。
嗯，说了这么多，其实核心就一句话：汽车软件的CI/CD，不是简单的「代码提交→自动构建→自动部署」，而是一个需要精心设计的系统工程。它要兼顾效率、质量、安全和合规。后面几章，我会带大家一步步搭建一套真正可用的汽车软件CI/CD流水线。
今天就到这里。下一章我们开始动手，先搭建Jenkins环境，配置Vector工具链的集成。到时候我会分享一些具体的配置文件和踩坑经验。