定义
CI/CD（Continuous Integration / Continuous Deployment）即持续集成与持续部署，通过自动化流水线完成代码构建、测试、签名、发布。设备管理平台可将固件构建与 OTA 发布集成到 CI/CD，实现版本快速迭代，配合 Changelog 自动生成。
流水线阶段
典型 CI/CD 流水线包括：代码提交触发、编译/构建、单元测试与集成测试、静态分析与安全扫描、固件签名（Firmware Signature）、打包与版本打标、上传至 OTA 服务、可选灰度发布。设备管理平台提供 API 或 Webhook，供 Jenkins、GitLab CI、GitHub Actions 等工具调用，实现「提交即构建、构建即发布」的自动化闭环。
在设备管理中的应用
固件开发团队通过 CI/CD 将构建产物自动上传至平台 OTA 模块，减少人工上传错误；可配置自动创建灰度任务、生成 Changelog、通知相关方。平台侧支持版本校验、签名验证，确保只有通过流水线验证的固件才能下发，提升 OTA 安全性与发布效率。
最佳实践
建议将固件版本号与 Git Tag 或构建号绑定，便于追溯；在流水线中加入设备模拟测试或真机冒烟测试；对生产发布采用人工审批或分阶段灰度，避免全量推送风险。
流水线可以自动走到哪一步
持续集成与持续部署在设备管理里的技术含义，是用同一套可重复的步骤把源码变成可签名的固件，并把它登记到发布库，而不是指每一次提交都立刻写进全部在运设备。自动部分通常停在：编译、测试、签名、生成版本说明、上传到指定产品的候选区。从候选区到现场任务，还要有人确认适用的硬件版本、源版本范围和推送批次。流水线只有在构建环境、签名密钥和产品标识都固定时才有意义；密钥若放在开发者笔记本上，换一台机器就不再是同一条流水线。
适合收进流水线的，是已经有稳定产物格式和版本号规则的固件。仍在频繁改分区布局或协议的早期版本，可以自动编译和测试，但不应自动进入可对现场下发的目录。每条构建要留下源码修订号、依赖版本和签名结果，以便日后对照某台设备上的版本。与A/B 分区相关的镜像，还要在流水线里检查槽位体积是否装得下，避免包在云端显示可发布、到设备上却写不进空闲槽。
未签名包进入发布通道
容易出错的是测试通过被理解成可以跳过签名。测试环境为了图快关闭校验后，同一条流水线若被复制到生产，未签名或用测试密钥签的包就会进到发布列表。另一种错误是构建号变了、版本号没变，设备端按版本号判断“已是最新”，从而拒绝或重复安装同一号的不同内容。还有把失败步骤设成可忽略，签名或打包失败仍继续上传，平台上会出现残缺包。
人工放行若只看流水线绿灯、不看产物对应的硬件，会把仅在新主板验证过的包推给旧主板。灰度比例和观察时间也不该写死在脚本里无人能改。灰度发布的第一批结果应回到流水线记录里，决定是否允许下一批，而不是构建结束就默认全量。密钥轮换时要分清旧包仍可用旧公钥验证、新包必须用新密钥，两条链在过渡期并存，不能在一天之内把验证材料全部作废。
候选包和现场任务的分界
流水线把包送进发布库，只说明这个产物可被选择，不说明它已经得到对某批现场设备下发的许可。候选区和可执行任务之间应有一次明确的放行：核对硬件修订、适用的源版本、签名所用的密钥以及变更说明是否对得上这个包。放行的人要能看懂失败的测试是被忽略了还是真的通过了。把生产任务的创建也写成提交代码就自动发生，等于让每一次合并都可能触达现场。测试分组上的自动安装可以保留，它的目标应是固定的试验设备，不能和客户现场的动态范围共用同一个触发器。
构建环境本身也要可重复。依赖版本浮动、签名机器的时钟错误、或脚本在失败后继续上传，都会产生一个绿灯但内容不可信的候选包。产物应带有源码修订、构建号和哈希，现场设备上报的版本要能回到其中一项。只有版本号、没有构建号时，两个内容不同的包会在列表里看起来像同一个。密钥轮换期间，旧候选包和新候选包要用各自的验证材料说明，不能在放行记录里混成“已签名”。分界清楚之后，流水线加快的是准备时间，现场风险仍由放行和分批来控制。