第1章嵌入式 CI/CD 全景剖析：为什么要用，怎么落地？

在传统的嵌入式开发中，工程师往往依赖手工编译、手动烧录、人工测试和人工发布，流程繁琐且易出错。随着产品功能复杂度持续攀升、市场节奏持续加快，“手工流水线”已无法满足敏捷迭代与高质量保障的需求。引入 CI/CD（持续集成 & 持续交付/部署）理念，能够将代码构建、测试、打包、部署全流程自动化，让每一次提交都伴随快速、可重复、可追溯的交付闭环。

本章将从 嵌入式痛点、CI/CD 基本概念、架构模式对比、工具选型指南、整体系统架构示例 五大层面，全面剖析为何要在嵌入式领域落地 CI/CD，以及如何快速启动。

1.1 嵌入式开发的五大痛点

编译环境不一致

不同团队成员机器上，Linux 发行版、交叉编译器版本、依赖库均可能不同。

“在我这可以编译，在你那编译不过”的问题频发，调试耗时长。

构建效率低下

单次全量编译耗时可达数分钟到数小时。

小改动后仍需重新编译全部模块，不能增量构建或并行加速。

测试覆盖率薄弱

多数测试依赖手工操作：烧录到评估板上再手动验证。

无法快速回归测试，无法量化单元测试、集成测试和硬件在环测试的覆盖率。

发布与部署不透明

固件打包、签名、上传制品仓库和 OTA 服务端部署多靠人工。

版本管理混乱，缺乏统一的制品仓库，回滚成本高。

质量门槛缺失

缺少静态分析、代码复杂度、单元测试覆盖率等“质量门”自动阻断机制。

低风险 BUG 容易流入生产，维护成本上升。

1.2 CI/CD 基本理念与核心价值

1.2.1 什么是持续集成（CI）

持续集成（Continuous Integration）指的是开发者频繁地（通常每天多次）将代码合并到主分支，每次合并后都由自动化系统立即执行：

代码编译：使用统一的容器化或脚本化构建环境，保证结果一致。

单元测试：运行 CMock/Unity 等框架的单元测试，并生成测试报告。

静态分析：Cppcheck、Coverity、SonarQube 对代码质量进行扫描。

制品生成：将编译产物打包成制品（.hex/.bin），并上传到制品仓库。

这样可以及时发现集成错误，防止“集成地狱”现象，确保主分支始终处于可构建、可交付状态。

1.2.2 什么是持续交付/部署（CD）

持续交付（Continuous Delivery）在 CI 基础上，进一步将合格的制品自动化地：

打包签名：对固件进行数字签名或校验，保证上线可靠性。

上传制品仓库：如 Artifactory、Nexus、GitLab Package Registry。

部署到测试环境：通过脚本或服务，将固件刷写到硬件在环平台 (HIL)。

执行自动化测试用例：包含冒烟测试、回归测试，并收集日志。

持续部署（Continuous Deployment）更进一步，将测试通过的固件直接 OTA 下发到真实终端或灰度环境，实现最快的交付节奏。

1.2.3 CI/CD 在嵌入式领域的价值

质量可量化：代码覆盖率、静态分析门槛，自动生成可视化报告。

反馈实时：每次提交都能在几分钟到十几分钟内拿到完整反馈。

一致性保障：容器化环境+脚本化流程，彻底消灭“环境不同”问题。

迭代加速：从“写完代码手动部署”到“一键提交自动可交付”，周期大幅缩短。

风险可控：通过灰度部署、回滚策略，降低线上风险。

1.3 流水线架构模式对比

特性	自建流水线（Jenkins）	云托管服务（GitLab CI / GitHub Actions / Azure DevOps）
初始成本	需要自行购买/租用服务器、配置 Jenkins Master/Slave；管理和维护成本高	零服务器运维成本，按需使用 Runner 或 Hosted Agents
扩展性	灵活度极高，可自定义插件、节点，支持大规模并行；但需要额外配置与维护	扩展性依赖云平台配额和 Runner 数量，可能受限于免费额度
易用性	配置较复杂，学习曲线陡峭；Groovy 脚本或 UI 配置需长期维护	YAML 配置简单，社区示例丰富；与 Git 仓库高度集成，入门门槛低
安全性与隔离	私有网络内运行，数据更安全；但需自行打补丁、配置防火墙	云平台安全性由厂商保障；需要已关注 Runner 隔离和凭证管理
生态与插件	插件生态成熟，但版本兼容性有时需要手动调优；自由度高	原生集成多种云服务（Container Registry、Artifact Store、Secrets 等），社区模板丰富
成本模式	服务器及运维成本固定；插件部分可能收费	按使用量付费；免费套餐对中小团队友好

1.4 工具选型指南

Jenkins

适合有自建运维团队、追求高度可控和自定义的团队。

插件生态最全，支持分布式构建、Docker 镜像、OpenOCD 自动烧录等多种场景。

GitLab CI

与 GitLab 源代码托管完全集成，YAML Pipeline 简洁易懂。

自带 Container Registry、Package Registry，可一站式管理制品。

Runner 支持 Docker、Shell、Kubernetes Executor。

GitHub Actions

与 GitHub 仓库零配置集成，Action 市场丰富。

免费额度对开源项目友好，闭源项目需评估费用。

可借助 self-hosted Runner 在本地或私有网络中完成交叉编译、烧录等操作。

Azure DevOps

微软生态下的全流程 DevOps 平台，涵盖 Boards、Repos、Pipelines、Test Plans、Artifacts。

Pipeline 支持 YAML 与可视化界面。

对于已经使用 Azure 生态（如 Azure IoT Hub）的项目尤为适合。

1.5 整体系统架构示例

下面以 C4-PlantUML 为基础，给出一个简化的嵌入式 CI/CD 系统架构示例：

@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml

Person(dev, "嵌入式开发工程师", "编写代码、编写测试、维护脚本")
System_Boundary(ci_cd, "CI/CD 平台") {
  Container(repo, "代码仓库 (GitLab/GitHub)", "存储源代码与版本管理")
  Container(pipeline, "CI/CD Pipeline", "自动化构建/测试/部署流程")
  ContainerRegistry(registry, "制品仓库
(Docker/Package Registry)", "存放编译产物与固件包")
  Container(hil, "硬件在环 测试平台 (HIL)", "自动刷写 & 执行硬件测试")
  Container(ota, "OTA 更新服务", "将固件推送到设备")
}

Rel(dev, repo, "Push 代码 & MR")
Rel(repo, pipeline, "触发 Pipeline")
Rel(pipeline, registry, "推送 镜像 & 固件")
Rel(pipeline, hil, "自动刷写 & 运行测试")
Rel(pipeline, ota, "自动触发 OTA 发布")
Rel(ota, dev, "更新设备 & 收集反馈")

@enduml

说明：

代码仓库：Developer 提交代码后触发。

CI/CD Pipeline：包括编译、单元测试、静态分析、HIL 测试、制品打包上传、OTA 发布等阶段。

制品仓库：存储 Docker 镜像、.hex/.bin 固件包，以及版本标签。

硬件在环测试：基于 STEVAL-IDB011V1 等板卡，实现自动刷写与脚本化验证。

OTA 更新服务：将新固件推送到远程设备，并收集升级结果与日志。