通过eva skoglund.

我有一个亨希 - 连续部署将是嵌入行业的下一个重要变化。考虑一下，连续集成工作方法符合设备互联网连接，你得到了什么？连续部署新服务和功能直接进入连接到网络的实时网络和设备。

持续部署已经在某些行业中使用，例如Web托管服务（Facebook，Netflix）和电视广播。但它对嵌入式设备没有意义，因为它们通常只是独立设备。但在IoT和互联网连接的世界中没有了......在设备连接到网络的情况下，突然部署突然发出了很多意义。

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

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

所以现在你可以认为“连续部署......在嵌入式开发中......我不这么认为！“我选择不同意。嵌入式空间中的连续部署如何不遥不可及？

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

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

当然，由于嵌入式设备的软件如此紧密地连接到特殊构建的硬件，因此与它的普遍世界相比，情况不同。大卫罗森的博客从去年开始，持续交付也很好地描述了：

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

所有上述复杂因素都让它感觉像真正的敏捷和连续做法，包括持续交付和连续部署，这只是嵌入式开发人员的乌托邦。我们怎样才能设法快速而简单的发布过程？脱颖而出的常见线程，并闪耀到所有这些都是a）缺乏立即和无处不在的目标硬件访问，b）缺乏改变和修改硬件的灵活性。

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

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

我们成功的simics.使用其最终客户之一的持续部署服务的客户无法足够强调短的交货时间的重要性。正如上面的博客文章所说“如果您当前的构建，测试和分析过程更接近更长的时间超过您的开发人员重新填充他们的咖啡时，我的建议将是优先考虑这一问题的关键改进。”制作构建测试释放周期的端到端时间短暂也许是解决的最重要的方面。当组织中的每个人都无限制地访问虚拟目标硬件，这可能是可以自由地改变和缩放的，突然间，您有一个技术基础设施，使得可以显着缩短交货时间。

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

PS。

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