3. 持续集成核心概念与流水线设计

在 Simulink 模型的开发过程中，持续集成（Continuous Integration, CI）并不是简单地把模型文件放进版本库、再定时跑一次仿真。它是一套围绕“频繁集成、快速反馈、可重复构建、可追溯制品”建立起来的工程约束。对于模型驱动开发而言，CI 的核心对象不只是源代码，还包括 .slx 模型、数据字典 .sldd、需求链接、测试用例、代码生成配置以及标定数据。理解这些对象在流水线中的流转方式，是设计可靠 CI 的前提。

CI 的四条基本原则

第一条原则是单一可信源。所有模型、脚本、测试和配置都必须纳入版本控制，任何构建都只能从版本库的指定提交（commit）拉取，禁止依赖工程师本地未提交的改动。第二条是频繁提交与短生命周期分支。分支存活时间越长，合并冲突和模型差异越大，Simulink 的图形化差异尤其难以人工比对，因此建议分支生命周期控制在一天以内。第三条是构建可重复。同一提交在任意时间、任意代理节点上应产生一致的构建结果，这要求固定 MATLAB 版本、固定依赖工具箱、固定编译器与目标硬件配置。第四条是失败即停止并通知。流水线一旦在某个阶段失败，后续阶段不应继续消耗资源，同时必须把失败原因和责任人快速推送出去。

构建触发机制

构建触发决定了流水线何时启动。常见触发方式包括：提交触发（push）、合并请求触发（merge request）、定时触发（schedule）和手动触发（manual）。对于 Simulink 项目，推荐以合并请求触发为主、定时触发为辅。合并请求触发能在代码进入主干前完成模型检查与回归测试，避免污染主干；定时触发则用于夜间执行耗时较长的全量回归、代码生成与覆盖率统计。

触发时还需考虑路径过滤。例如仅当 models/、tests/、scripts/ 目录发生变化时才触发完整流水线，而文档目录变更只触发轻量检查。这样可以显著降低构建队列压力。另一个关键参数是并发控制：同一分支的新提交应取消尚未完成的旧构建，避免资源浪费和结果错乱。

流水线阶段划分

一条面向 Simulink 的典型流水线可划分为五个阶段：准备、静态检查、模型测试、代码生成与验证、制品归档。准备阶段负责检出代码、恢复依赖、启动 MATLAB 并加载工程；静态检查阶段执行模型规范检查（如 Model Advisor）、命名规范、未连接端口、采样时间一致性检查；模型测试阶段运行单元测试与回归测试，输出测试报告；代码生成与验证阶段针对目标配置生成嵌入式代码，并执行 SIL/PIL 对比；制品归档阶段保存模型、生成代码、测试报告和覆盖率数据。

阶段划分的关键是快速失败：把耗时短、命中率高的检查放在前面。例如模型规范检查通常只需几十秒，而全量回归可能需要数十分钟，因此静态检查应优先执行。下表给出一个可参考的阶段配置示例，参数为教学假设值，实际项目需按模型规模调整。

制品管理与反馈机制

制品（artifact）是流水线每个阶段产出的可追溯文件。对 Simulink 项目而言，至少应归档：构建后的模型快照、生成的 C 代码、测试结果 .mldatx 或 JUnit 报告、覆盖率数据、Model Advisor 报告以及构建日志。制品必须与提交哈希、构建编号、MATLAB 版本绑定，便于问题复现。建议保留最近 30 次成功构建的制品，失败构建的日志保留 90 天。

反馈机制的核心是让失败信息可读、可定位、可行动。通知内容不应只有“构建失败”，而应包含：失败阶段、失败用例名称、错误摘要、日志链接和责任人。对于模型测试失败，最好直接给出仿真时间点、信号名和期望值与实际值的差异。反馈渠道可包括邮件、即时通讯工具和合并请求评论。实践中，将失败摘要自动回写到合并请求，能显著缩短修复周期。

把上述机制串起来看，持续集成的价值不在于“自动跑了一次仿真”，而在于每次提交都能在受控环境中完成从模型检查到代码验证的完整闭环，并把结果以可追溯的制品和可行动的通知形式返回给开发者。流水线设计得越清晰，模型迭代的节奏就越稳定，后期集成风险也越可控。