第1章嵌入式持续交付概述

嵌入式持续交付概述：从传统瀑布模型到敏捷开发

说实话，我入行那会儿，嵌入式开发还处在「写代码→烧录→看现象→改代码」的原始阶段。那时候团队七八个人，共用一台仿真器，谁要调试得排队。项目周期动辄一年半载，交付前通宵达旦是家常便饭。

后来我慢慢意识到，这种模式其实是在赌运气。你想想看，硬件改版一次几万块，软件出bug可能直接导致芯片回片失败。嗯，这就是为什么我们需要聊聊持续交付——它不是什么花哨的概念，而是实打实的救命稻草。

瀑布模型长这样：需求→设计→编码→测试→部署。听起来挺清晰，对吧？但我在实际项目中吃过它的亏。

有一次做车载控制器的项目，需求文档写了三百页。等我们硬件设计完、软件写完、开始系统测试时，才发现最初的通信协议选错了。改？硬件要重新打板，软件要重写驱动层。项目延期三个月，老板脸都绿了。

瀑布模型的核心问题在于：反馈周期太长。嵌入式开发中，硬件和软件的耦合度极高。你不可能等所有东西都做好了再回头改。说白了，这就像盖房子，地基都打好了才发现图纸画错了——代价太大了。

  我个人的经验是：瀑布模型适合需求极其稳定、硬件已经成熟的场景。但凡你的项目涉及新芯片、新协议、新算法，千万别用瀑布。否则你会发现自己大部分时间都在「擦屁股」。

敏捷开发在互联网圈火得一塌糊涂。两周一个迭代，每天站会，持续集成。但嵌入式团队照搬这套，往往会碰一鼻子灰。

为什么？因为嵌入式有它的特殊性：

我记得有一次，团队想学互联网公司搞每日构建。结果呢？编译一次要40分钟，因为要交叉编译、链接、生成镜像、烧录到开发板。大家每天花一小时等编译，效率反而下降了。

所以我的建议是：别全盘照搬敏捷，要取其精华。比如每日站会、看板管理、小步迭代这些理念，完全可以落地。但持续集成的节奏、测试策略，必须根据嵌入式特点来定制。

这个问题，我当年也问过自己。直到有一次，我在一个无人机飞控项目上栽了跟头。

那个项目有6个开发人员，各自负责不同的模块。有人改了一个传感器驱动，结果影响了另一个人的姿态解算算法。等集成测试时才发现，但已经过去两周了。定位问题又花了一周。你算算，一个bug从引入到发现，整整三周。

CI/CD能解决什么？说白了就是：让问题尽早暴露。

你想想看，如果每次提交代码后，系统自动帮你编译、烧录、跑一遍单元测试和集成测试，有问题的代码根本进不到主线。这能省下多少扯皮的时间？

一个小技巧：我在项目中习惯把CI流水线分成三级。第一级是快速检查（编译+静态分析），5分钟内出结果。第二级是单元测试，跑在模拟器上。第三级才是硬件在环测试。这样既能快速反馈，又不会因为硬件资源不够而阻塞开发。

做嵌入式CI/CD，最大的挑战不是技术，而是硬件资源管理。你不可能给每个开发者配一套开发板，更不可能让CI服务器同时跑几十个硬件测试。

我曾经在一个项目中，CI服务器上挂了8块开发板。每次提交代码，流水线自动分配一块空闲板子来跑测试。听起来挺美好，对吧？但问题来了：

嗯，这些都是血泪教训。后来我总结了几条避坑指南：

我曾经踩过的坑：

还有一个挑战是测试覆盖率。嵌入式系统里，很多bug是时序相关的、中断相关的、资源竞争相关的。这些bug在模拟器上根本复现不了。怎么办？我的做法是：

说白了，没有银弹。你得根据项目特点，找到测试投入和风险之间的平衡点。

说了这么多挑战，你可能会问：值得吗？我的回答是：绝对值。

我参与过一个汽车电子项目，从零搭建了CI/CD流水线。刚开始大家觉得麻烦，觉得「多此一举」。但半年后，数据说话了：

更重要的是，团队的心态变了。以前大家害怕改代码，因为不知道会引入什么bug。现在呢？每次提交都有自动化测试兜底，改起来心里有底。这种心理安全感，是敏捷开发最宝贵的财富。

  我的总结：嵌入式CI/CD不是锦上添花，而是雪中送炭。它不能解决所有问题，但能帮你把问题控制在可控范围内。尤其是当你的项目涉及安全关键系统（汽车、医疗、工业控制）时，CI/CD不是可选项，而是必选项。

好了，这一章我们聊了从瀑布到敏捷的演进，嵌入式CI/CD的必要性、核心挑战和收益。下一章，我会具体讲讲如何搭建一个适合嵌入式团队的CI/CD流水线。到时候我会分享一些具体的工具选型和配置经验，都是我实际用过的方案。