由嘉宾作者Jakob Engblom

持续交付(CD)和持续集成(CI)是现代软件工程和软件产品开发中两个相关而重要的概念。做集成是先决条件做交付和部署,并得到一个CI流往往是最难的部分的CD。做CI服务器等通用软件在一台通用计算机或网络系统相对比较简单,但做嵌入式系统是更困难的。我最近发现了一个很好的技术在网上聊关于嵌入式系统连续交付的主题，以及如何实现它。我所做的一件事是在这种开发和测试流程中的显而易见的作用和需要模拟。

迈克龙（鼓舞人心）谈话

启发我重新讨论这个话题的演讲是“嵌入式系统的持续交付”，可以在下面找到https://vimeo.com/131632946。扬声器很长的是迈克Praqma*，一个斯堪的纳维亚咨询室软件交付，专注于嵌入式系统。这是对主题的一个非常好的介绍。我建议在继续之前看看谈话。

你确实看了，对吗？

对我来说，演讲的关键是工具和过程非常重要，嵌入式系统可以从由正确的工具支持的良好过程中受益，就像软件开发的其他领域一样。关键是找到工具并构建用于系统的流，这些系统根据定义具有与环境的广泛接口。他的许多观点大家都很熟悉，他也有一些很好的新观察。

要点

Mike Long最重要的信息是，软件开发方法和工具很重要，“嵌入式”并不是不以现代和高效的方式工作的借口。根据他的经验，相当多的嵌入式软件是作为物理系统开发的一个不重要的事后考虑而完成的。他谈到开发人员不使用版本控制或自动构建系统。相反，他们将现有源代码的副本作为下一个产品的起点，在他们的笔记本电脑上构建二进制文件，然后简单地将生成的二进制文件交付给生产系统。返回去再现以前的版本是不可能的，而且每次交付都需要大量的手工工作。

这种系统并不完全是促进软件质量的可扩展系统。什么嵌入式软件组织（实际上，任何软件组织）应该做的是设置CI系统。

这真的不是我所习惯看到的。我似乎有幸与一些成熟的嵌入式系统公司进行过交谈，这些公司为其软件配备了CI，并且正在使用持续交付甚至持续部署来增加他们所提供的系统的客户价值。要做到这一点需要努力，但这是值得的。还会出现一些工具问题，稍后再讨论。

Mike Long的CI对嵌入式系统的看法是您有一个单独的开发人员步骤，您可以在提交后执行基本集成，然后您对主CI异步进行。他勾勒出一种看起来像这样的流程（从视频中所示的插图重新绘制）：

之前我没有想过的一个重要点是提交和基本代码集成（合并）和构建必须从主CI流中解耦。主要的CI管道可能需要数小时甚至几天才能为提交运行，并且您不想阻止开发人员那么长时间。

看到静态分析和文档显示为持续集成管道中的各个阶段，我感到很振奋。我自己倾向于主要关注在各种上下文中运行代码，但是这里提出的方法不仅包括了更多的技术来提高软件质量(静态分析)，还包括了使软件准备交付所需的步骤(文档和最终验证)。

然而，我可以看到一个风险，如果测试管道太长——开发人员不断集成最终被拒绝的代码。我们曾经在一个客户那里看到过这一点，在硬件上运行验证测试需要一周的时间。这意味着问题会在回归测试中被重新引入和捕获，因为测试结果回来得太晚了，无法提供帮助。

避免这种情况的关键是按顺序做事，这样才能尽快获得反馈。在这种情况下，从静态分析开始很可能会在早期发现许多小问题。一旦通过，将部署到测试系统并运行所有功能测试将在合理可行的情况下尽快发现代码级问题。这意味着代码相关的反馈将在可行的情况下尽快发送给开发人员。

文档和最终验证只有在代码本身通过功能测试并且相当可靠时才会发生。在那里发现的问题可能是高层次的，不一定与小的代码更改有关。任何CI管道的后期阶段都可能需要几天甚至几周的时间，这取决于域的需求。

换取解决硬件问题

正如Mike Long所描述的，问题的核心部分是开发人员需要访问“类似于生产的环境”。你想要确保软件可以在真实的东西上闪现和引导-但在实践中，硬件将会延迟，或原型阶段，或脆弱，或以上所有。这是虚拟平台能够真正发挥作用的问题之一——它们提供了一个稳定的执行平台，与真正的平台非常接近，功能测试可以使用真正的代码运行。

一旦代码正在运行，CI的下一部分用于嵌入式软件就是确保代码从世界获得合理的输入。嵌入式软件不仅涉及与其他代码或其他计算机系统通信，还涉及通过传感器和其他接口的环境。测试需要通过真实系统中使用的硬件接口向正在测试的系统中发送代表数据。

因此，用于嵌入式系统的现实世界实验实验室需要处理几种独特的挑战：

• 使正确的硬件可用于运行测试 - 需要知道您可以在这有意义的情况下运行
• 将软件加载到硬件上——这可能容易也可能困难，这取决于硬件上的软件堆栈的性质
• 集成环境——您需要向硬件提供合理的刺激，使代码相信它在现实世界中运行，并观察它对现实世界情况的反应

一个典型的硬件实验室设置是这样的:

您有特殊的硬件来运行测试，您需要两个机器。一个用于控制和配置所测试的系统，以及提供所需的各种输入。作为Mike Long Notes，有时您将存根添加到被测试的软件中以简化数据发生器的工作。但是你无法远离需要提供某种刺激的模拟。你不能一般地把系统进入其真实世界的背景来测试它 - 这种测试通常是艰难的，危险的，与行业法规相反，或者不可能将实验室挤压到实验室中。这外部环境(世界)只能被模拟。

通过将世界模拟与系统硬件的虚拟平台模型相结合，我们可以将整个设置转换为可以在任何服务器或PC上运行的软件工作负载。

像这样：

这使硬件可用性主要消失，并使测试更可靠。即使仿真设置是对许多单独的模拟器的合并，只要它是所有软件，即可自动化并以一种对纯硬件不可行的方式来控制它。

这样的软件模拟可以以一种硬件实验室无法做到的方式进行扩展——每个硬件实验室实例都必须构建和维护。软件模拟可以很容易地复制到更多的服务器或pc上，从而提高测试系统的可用性，不会减慢进度。如果测试系统可用性是测试的一个限制因素，那么您自然就必须测试更少，以确保进展。这将导致更糟糕的软件，因为必须限制测试和测试覆盖率，将测试运行压缩到可用的测试执行时间预算中。

这就是我之前在长达一周的回归测试中谈到的用户所做的——他们使用了许多并行的虚拟平台实例来消除作为瓶颈的执行平台。这使得他们能够在一夜之间运行一个完整的回归套件，而不是超过一个星期。通过这种方式，重新引入错误的窗口减少了，从而大大减少了开发人员的挫折感，提高了代码质量。

更多的变化

无论使用实体平台还是虚拟平台，使用模拟来产生真实世界的刺激都是可行的测试场景在现实世界中很难实现天。模拟让您突破您可以在最终系统中诱导的狭窄情景，以及复制在现实世界中观察到的奇怪情况。

正如我在a中所描述的那样以前的博客:

请注意，模拟不必基于软件...... Mike Long指向使用乐高* Mindstorms *的可爱硬件模拟器，并用于以可重复的方式测试小雷达传感器：https://www.xethru.com/blog/posts/breath-simulation-with-xethru-bot。但是，如果将其放入实验室，您将重新返回少量硬件资源作为测试瓶颈 - 但后来，您现在可以测试真实的电子产品，这是最终验证和测试所必需的。

通常，在真实世界、模拟的物理系统和基于软件的模拟之间来回跳跃提供了可能最丰富的测试环境。基于软件的模拟允许软件测试扩展并完全自动化，而基于硬件的模拟是测试最终硬件和软件的必要条件。

Mike Long提到的另一个变化方面是在构建中使用多个不同的编译器来提高代码质量这是我长期以来最喜欢的方法。您希望在任何地方注入变化 - 但是可预测和可重复的变化。

最后的笔记

我已经写了相当广泛的虚拟平台和软件仿真如何简化嵌入式系统的持续集成。我发现了迈克的这种特殊谈判，长时间谈论CI和CD的重要性，有很多来自各公司的轶事和现实世界的例子。在最后，他讨论了特斯拉如何能够快速将新软件部署到他们的汽车，从连续交付到连续部署，因为拥有更新机制以及接受正在进行的更新的用户群。

搬到连续交付是嵌入式系统的关键竞争优势。随着越来越多的系统连接在一起，能够轻松部署更新后的软件将从一个不错的奖励变成期望的功能。就像桌面、移动应用程序和操作系统已经预期到的那样。处于CD流中能够让开发者更快乐，并更容易吸引关键人才。

为了实现这一点，嵌入式软件的测试必须从完全依赖硬件到仿真和虚拟平台。不仅适用于早期软件开发，而且适用于产品的整个生命周期。

*文章最初发表于英特尔软件开发人员区域。