通过Eva Skoglund

我有一种预感——持续部署将是嵌入式行业的下一个重要变化。想想看，不断集成的工作方法满足设备上网连接，你会得到什么?将新服务和功能直接部署到现有网络和连接到网络的设备中。

持续部署已经在一些行业中得到了应用，比如网络托管服务(Facebook, Netflix)和电视广播。但这对嵌入式设备来说没有意义，因为它们通常只是独立的设备。但现在不是了……在一个物联网和互联网连接的世界里，设备可以连接到网络，突然间持续部署就变得很有意义了。

由于敏捷方法已经进入嵌入式领域并得到广泛应用，因此持续部署的技术基础已经就位。敏捷方法不再仅仅被视为“时髦的工程”，它被广泛地接受和引入到任何地方，甚至在最谨慎的工程环境中也是如此。伴随敏捷方法而来的往往是持续集成的实践，有时还有“小组团队”——将工程团队组织成更小的单元，负责从设计、实现和测试到最终集成的所有事情。最重要的是测试自动化和每晚的测试和构建系统。你现在得到的是新功能的开发，完整的产品测试和集成，在每1 - 3周的冲刺中内置到最终系统中。

采取持续部署的步骤并不大。好吧，考虑到所涉及的努力，以及它将产生的变化和影响，这是一个很大的步骤。我的意思是:持续部署是自然的扩展已经在使用的实践，如果你做敏捷和持续集成。我的一个研究机顶盒的朋友告诉我，“我们已经实现了持续集成，而且每个人都一直很匆忙，所以持续部署的步骤就这样发生了。”

所以现在您可能会想“持续部署....”我不这么认为!”我选择不同意。嵌入式空间的持续部署为何不是遥不可及?

与任何持续实践一样，嵌入式软件开发也存在一些需要解决的特殊挑战。因为这Mike Bria的博客从2009年开始，至今仍然适用:

• 由于相应的硬件可能不容易获得，因此测试不断发展的软件会更加困难。
• 改变想法的自由更少，因为相应的硬件改变可能带来不可接受的高成本
• 考虑到硬件构造可能需要更超前的规划和设计风格，利用“边走边学”技术的能力较低。

当然，由于嵌入式设备的软件与专用硬件紧密相连，这种情况与一般的IT世界不同。大卫·罗森的博客从去年开始关于连续交付也描述得很好:

• 大量的遗产．在代码库方面，还有产品架构、团队组织、构建系统和测试环境方面。
• 贪得无厌的需要计算基础设施．众所周知，使用C/ c++的构建时间很长，而且需要大量的CPU。
• 难以有效整合和管理测试自动化当您依赖于物理目标的手动配置和部署时。
• 与Java和。net等托管环境相比，C/ c++编程范式中典型的基线构建和分析的前置时间要长得多。
• 与法规要求(如IEC 61508、DO 178-B等)进行验证的成本高且耗时。

以上所有复杂的因素，让人觉得真正的敏捷和持续实践，包括持续交付和持续部署，对嵌入式开发人员来说简直就是乌托邦。我们如何才能拥有一个快速且简单的发布过程?最让我印象深刻的是:1)缺乏对目标硬件的即时和无处不在的访问;2)缺乏改变和修改硬件的灵活性。

但是…如果你有即时访问所需的所有目标硬件(以至于你可以并行化任何活动可以并行化),如果你能改变目标硬件在眨眼之间,没有成本,尝试你的新软件变化——这意味着什么?它将如何影响您的开发过程、您的工具基础结构和测试自动化?

一个虚拟目标，一个完整的系统模拟器，它可以在一个受管理的模拟环境中运行没有改变的生产二进制文件，这正好解决了这个问题。

我们成功的西米奇那些与最终客户之一进行持续部署服务试点的客户，现在再怎么强调短交货期的重要性也不为过。正如上面的博文所说:“如果你当前的构建、测试和分析过程比你的开发人员重新填满他们的咖啡所花费的时间更长，我的建议是优先考虑这一点，作为一个关键的改进。”缩短构建-测试-发布周期的端到端时间可能是需要解决的最重要的方面。当组织中的每个人都可以无限制地访问虚拟目标硬件(可以自由地更改和扩展)时，突然间你就有了一个技术基础设施，可以大大缩短交付时间。

因此，这就是为什么我的结论是，当敏捷实践和持续集成满足设备互联网连接时，当嵌入式挑战可以通过使用全系统模拟作为工具基础设施来克服时，我们正在嵌入式行业中看到持续部署的光明。

PS。

顺便说一下，连续的区别交付和连续部署在部署到生产环境之前删除手动步骤。阅读更多的卡尔Caum这里．