3. CI与版本治理核心概念

在ST Stellar这类车载MCU的量产软件项目中，代码不是写完就结束，而是要在多年生命周期内持续维护、修复、升级并满足功能安全与网络安全审计要求。持续集成、持续交付、版本控制、基线、分支策略、制品库与可追溯性，共同构成了一套“让每一次变更都可控、可查、可复现”的工程机制。理解这些概念，关键不是背定义，而是看清它们之间的数据流与约束关系。

持续集成：把集成风险前移到每次提交

持续集成（CI）的核心动作是：开发者把代码推送到共享仓库后，由自动化流水线立即完成拉取、编译、静态检查、单元测试和链接，并给出通过或失败结论。对Stellar项目而言，一次典型的CI流水线可能包含：拉取源码与子模块、调用编译器构建MCU固件、执行MISRA C静态检查、运行单元测试、生成ELF与map文件、归档日志。若任一环节失败，流水线立即停止并通知提交者，避免缺陷流入后续阶段。

CI的价值在于“快速反馈”。假设某次提交误改了时钟初始化寄存器配置，若等到集成测试阶段才发现，定位成本会成倍增加；而在CI阶段，编译或单元测试即可暴露问题。需要强调的是，CI不是“每天构建一次”，而是每次提交都触发，且构建结果必须可重复。

持续交付：让可发布版本始终处于就绪状态

持续交付（CD）是在CI基础上，把通过验证的制品自动推进到“可发布”状态。它并不等于自动上线，而是保证任意时刻都有一个经过完整验证、可以随时交付给测试或客户的版本。对车载软件，持续交付通常包括：生成带版本号的固件包、执行集成测试、生成发布说明、将制品推入制品库并打标签。是否自动烧录到台架或整车，取决于项目阶段与安全策略。

版本控制与基线：给每个状态一个唯一坐标

版本控制（如Git）记录每一次变更的作者、时间、内容和原因。但仅有提交历史还不够，量产项目需要“基线”：在某个关键节点（如样件交付、法规认证、量产冻结）上，把源码、配置、工具链版本、脚本和文档固定为一组不可随意改动的快照。基线一旦建立，后续修改必须通过变更流程，并产生新的基线。

例如，某Stellar项目在B样件阶段建立基线 BL-B-SAMPLE-01，它对应的不是单个提交，而是一组标签：应用代码 v1.2.0、AUTOSAR配置 cfg-1.2.0、编译器 GCC 10.3、构建脚本 build-1.2.0。只有这组坐标同时确定，才能复现出完全相同的固件。

分支策略：让并行开发不互相污染

分支策略决定代码如何并行、如何合并、如何发布。常见做法是主干开发加发布分支：main 保持随时可集成，功能在短生命周期分支上开发，通过合并请求（MR）评审后合入；发布时从 main 切出 release/1.2，只接受缺陷修复，不再引入新功能。修复需同时回合到 main，避免版本分叉后遗漏。

对功能安全项目，分支保护规则必须开启：禁止直接推送 main、要求至少一名评审人、要求CI通过后才能合并。这样，分支策略就不只是“习惯”，而是可审计的强制约束。

制品库与可追溯性：从需求到二进制的一条链

制品库用于存放构建产物：ELF、HEX、map、测试报告、发布说明等。它与源码仓库分离，但通过版本号和元数据关联。可追溯性则要求：每个制品都能回答“它由哪次提交、哪套配置、哪个工具链构建”，并能反向追溯到需求与测试用例。

实现可追溯性的常见做法是：在构建时把Git提交哈希、分支名、构建编号写入固件版本信息区；制品库记录该制品的元数据；需求管理工具中的需求ID与测试用例ID建立链接。这样，当出现现场问题时，可以通过版本信息快速定位到源码与测试记录。

关键约束与常见误区

第一，CI必须与版本控制强绑定。没有提交触发的构建，只是定时任务，不能称为持续集成。第二，基线不是“最新代码”，而是“被批准的一组固定版本”，任何改动都要走变更流程。第三，制品库中的制品必须与源码提交一一对应，不能出现“手工修改后重新打包”的情况，否则可追溯性断裂。第四，分支策略要配合保护规则，否则再好的策略也会被绕过。

一个可参考的版本治理检查清单

把这些机制落地后，团队获得的不是“更多流程”，而是更低的返工成本和更强的交付信心。每一次提交都有构建结果，每一个发布都有基线坐标，每一个制品都能追溯到源码与需求——这才是量产软件版本治理的真正目标。