大家好，欢迎来到立芯嵌入式。
在一些高端产业里，嵌入式开发早已不再是单纯的软硬件拼凑，智能汽车、医疗设备、工业机械，哪一个不需要软硬件紧密配合？传统的开发方式，软件硬件各干各的，效率低不说，还容易出问题。市场可不等人，客户需求变来变去，周期还得压缩。持续集成/持续交付（CI/CD）作为一种敏捷开发方式，能对我们的开发流程起到非常大的帮助。
虽然持续交付在互联网行业中已是标配，但在嵌入式领域却仍处于探索期，只有少数一些大厂拥有较为完善的CI/CD流程。
什么是持续交付？
持续交付的核心理念就是让软件开发像流水线一样顺畅：代码随时可以构建、测试、部署，确保产品能够以最快的速度、最高的质量交付到用户手中。它不只是自动化工具的堆砌，更是一种团队协作和责任共担的文化。
持续交付的魅力在于：它能让你的固件更新像发朋友圈一样简单，随时可发，哪怕出了问题也能快速回滚。
持续交付是啥？简单说就是快而稳
持续交付的核心就是让开发流程像流水线一样顺滑：代码随时能构建、测试、部署，产品随时能上线。听起来高大上，其实就是让开发、测试、部署这几步变成自动化的日常操作。
更重要的是，持续交付不只是工具的事，它还要求团队有种主人翁精神。开发、测试、部署，大家一起为产品质量负责，就像一个项目组里，硬件工程师和软件工程师得一起把板子调通。
嵌入式开发为什么要CI/CD？
嵌入式开发周期长，动辄几个月起步，但当前的市场节奏快得像双十一秒杀，慢一步可能就错失先机。CI/CD能把从写代码到上线的流程压缩到极致，堪比互联网产品的迭代速度。
比如我们开发一款智能穿戴设备，客户突然提出一个新功能需求。没有合理的devops流程，你得从头到尾手动测一遍，耗时耗力还容易漏问题。有了CI/CD，代码一提交，自动化测试立刻跑起来，问题当场暴露，部署也一键搞定，这个效率应该非常直观。
互联网公司早就玩转了这种快节奏，像一些大厂的App更新，基本每周都能推新功能。嵌入式里虽然硬件掣肘多，但用好持续交付，对我们敏捷开发也能起到非常大的帮助。
提高产品质量
嵌入式系统一旦出问题，可能就是设备直接挂，或者用户体验崩盘。持续交付通过自动化测试，把问题扼杀在摇篮里。单元测试、集成测试、系统测试，全部自动化跑一遍，Bug 没地方藏。
以前参与一个医疗设备的项目，早期全靠手动测试，每次上线都提心吊胆。后来上了持续交付流水线，每次提交代码，Jenkins 自动跑测试，问题直接暴露，客户投诉也少了。
持续交付该怎么搞？
版本控制
嵌入式开发不光要管代码，配置文件、测试脚本、硬件描述文件、甚至设计文档，都得丢进版本控制。这时候，Git就是首选。
Git 的分布式架构特别适合嵌入式开发，支持多人协作和复杂分支管理。
用 Git 的好处是，团队并行开发不乱套，分支管理让新功能开发不影响主线代码。如果出了问题，Git 的历史记录能快速定位到哪个提交搞砸了。
有次遇到固件崩溃，查了半天发现是配置文件版本没对齐。后来强制要求所有配置文件都进 Git，问题再也没出过。
自动化测试
系统一旦复杂，手动测试费时费力，还容易漏测。自动化测试是持续交付的灵魂，覆盖单元测试、集成测试和系统测试。
持续集成（CI）
持续集成要求团队频繁把代码合到主干，每天提交好几次，配合自动化构建和测试。
那CI服务器怎么办？Jenkins 开源灵活，插件多，几乎能适配所有嵌入式工具链。配置的时候尽量模块化，比如把交叉编译和测试脚本分开，后面维护起来方便。
之前团队用 Jenkins 搭建流水线，代码一提交，自动编译固件、跑测试，结果直接推送，大大提高了开发效率。
部署和回滚
嵌入式系统部署不能出错，搞不好设备直接变砖。持续交付要求部署流程高度自动化，还要能快速回滚。像物联网设备的 OTA 升级，配合版本控制和自动化测试，能确保新固件安全上线。
部署前在模拟器上跑完整测试，确认没问题再推到真设备。回滚策略也要提前备好，比如留个旧版本固件镜像，以防万一。
小结
CI/CD这套流程在嵌入式行业里虽然有点挑战，甚至很多小厂开发根本没听说过，但这一定是未来开发趋势，后续我们课程中也会深入讲解相关devops流程，帮助大家科学、规范地掌握嵌入式开发方法论。
