自行搭建嵌入式持续集成工具：从0到1

迪捷软件

于 2022-04-14 11:38:21 发布

阅读量387

点赞数

分类专栏： SkyEye 文章标签：嵌入式仿真建模仿真软件

本文链接：https://blog.csdn.net/digi2020/article/details/124163532

版权

SkyEye 专栏收录该内容

117 篇文章 21 订阅

订阅专栏

为什么持续集成备受推崇？

软件开发过程中，开发方式及开发工具是至关重要的。

持续集成（Continuous Integration，CI）以使产品在快速迭代的同时保持高质量为目的，指开发人员定期将代码变更合并到一个中央存储库中，系统自动运行构建和测试操作的过程。持续集成出现之前，开发人员需要手动编译打包最新代码进行测试，费时费力；且往往要在模块集成的最后关头才能发现被遗漏的错误的存在，而定位错误的具体位置又将消耗大量时间。

引入持续集成的必要性显而易见。

如何从零构建一个嵌入式持续集成工具？

5upercircuits的创始人Pla讲述了他自建嵌入式持续集成工具的过程[1]。

在建立之初，Pla希望这个工具尽可能地高效有用，满足动化、高品质、足够精简但有效的性能。他希望成品能够：

1. 自动执行当前必须手动、缓慢繁琐的工作；

2. 只要不断电，全天候24小时可用；

3. 拥有监控功能，可以立即汇报代码存在潜在的bug——这将大大降低调试难度，尽可能地确保软硬件的整体质量。

在经过细致的考量后，Pla最终决定：先利用docker部署嵌入式开发环境，然后通过GitLab的CI面板（GitLab内置的持续集成工具）对编写好的程序进行一键编译、烧录、运行和自动测试，达到持续集成的目的。

嵌入式持续集成的难点在哪里？

持续集成的设置通常包括：构建、测试、部署。

仅使用一个开发平台（如Web开发）实现持续集成并不难，但在嵌入式系统中却大不相同。首先，从构建的角度来说，开发者必须处理PC（一般是x86或ARM）与持续集成系统所使用的不同的处理器架构、操作系统和硬件之间的关系。但一般只要使用 makefile 和交叉编译器（例如 GNU Arm Embedded Toolchain[2]），自动化构建问题便会迎刃而解。

再者是测试，需要支持不同硬件架构的嵌入式系统可以正常运行，但大多数情况下，持续集成设置和待测设备 (Device Under Test，DUT) 不是同一硬件架构。Pla必须找到合适的接口和协议来进行持续集成设置和DUT的通信。

其他嵌入式系统公式是怎么做测试的？

许多嵌入式系统公司都在嵌入式开发中使用持续集成。在目标硬件上进行构建和单元测试是惯用手段。单元测试有着下述优点：

1. 立即发现代码中的潜在错误；

2. 更容易重构和扩展代码——单元测试确保了不会产生意外中断；

3. 使团队合作更加高效。

但单元测试不适合像Pla这样的自由职业者、业余爱好者，或初创公司。单元测试必须在目标系统上运行，或将代码移植到X86平台并在持续集成系统上运行。如果需要对代码中的几乎每个函数进行测试，这意味着测试量与代码量相同，这将导致消耗目标系统大量内存。而如果将代码移植到X86平台来避免内存消耗问题，则不得不在移植、伪造驱动程序耗费大量额外的时间和精力。这么做的目的是欺骗代码，使之认为自己是在目标硬件上运行的。

对于Pla来说，这两种情况都过于费时费力，无法接受。

该使用怎样的持续集成测试方法？

Pla选择了将单元测试和冒烟测试相结合的测试方法，并将之命名为命令行界面（Command Line Interface，CLI）测试：为在 x86 上运行的持续集成系统提供了一个接口，以便直接在目标平台上运行测试。

CLI测试为尽可能详尽的测试，甚至能直接访问最隐秘的系统功能，不需要在持续集成面板上运行，也无需移植，预处理器指令甚至可以暂时排除一些 CLI 测试。

Pla借此为不同的模块设置了不同的测试集，并且仅在需要时将其包含在构建中，从而降低了CLI测试的内存占用。

Pla的持续集成设置是什么样的？

Pla使用Gitlab来进行控制修订、备份，项目规划和笔记记录。Gitlab有一个非常精简的持续集成功能。Gitlab CI面板可以在普通Gitlab实例上运行。Gitlab Runner是一个用来执行Gitlab CI脚本的工具。可以理解成，Runner就像认真工作的工人，GitLab CI就是管理工人的中心，所有工人都要在GitLab CI里面注册，并且表明自己是为哪个项目服务。当相应的项目发生变化时，GitLab CI就会通知相应的工人执行对应的脚本。Gitlab Runner负责执行所有持续集成任务（例如构建、测试等）。