关于持续交付的概念，有很多通用的理论和原则，以及一个理想的产品开发组织应该如何努力在软件、硬件、配置或数据的每一次变化时，不断地向最终用户交付可发布的产品。关于如何在托管云和基于网络的产品开发领域中实现持续交付，还有大量可用的材料和实用建议，i、 e.当您作为一个产品开发组织，通常拥有并管理从开发到操作。每产品在其自身复杂的环境中发展。在这篇文章中，我的目的是解释和讨论在嵌入式产品开发中应用持续交付理论和原则的一些挑战和障碍。嵌入式和智能系统市场巨大，为成功的组织提供了万亿美元的市场机会。为了便于讨论，它包括但不限于以下行业的制造商和供应商：汽车、航空航天和国防、医疗设备、移动和消费电子、网络和电信基础设施、半导体和能源。如果您正在为您的嵌入式产品开发组织探索一个持续的交付实现，那么在撰写本文时，您会发现很难找到大量相关的实用参考资料，特别是如果您从企业规模的角度来看这一点的话。让我指出一个很好的参考，值得投资阅读、学习并从中获得灵感："大规模敏捷开发的实用方法：惠普如何改造LaserJet FutureSmart固件"。这本书将讨论惠普嵌入式打印机开发团队的转变历程，从他们所面临的问题和挑战的一个非常普遍的基础开始。作者在书中提出了一些非常有趣的想法和实用的解决方案，通过令人印象深刻的前/后统计和指标来支持结果。重要的是要注意实现持续交付的复杂性；这并不容易，而且需要大量的艰苦工作—无论您所在的行业、组织内的工作环境和基线起点如何。您需要认识到并理解一个成功的持续交付项目和实施是一个长期、复杂和雄心勃勃的组织变革。它不是一个交钥匙的解决方案或工具，它涉及到你的研发组织的所有方面。要成功，您需要一个坚实的平台，包括工具和基础设施、流程和配置管理，最后是人员和变更管理。向那些走了同样道路并愿意分享他们的经验的人学习，将极大地帮助你避免一些常见的错误。虽然定义持续交付的绝大多数一般理论和概念对嵌入式产品开发组织也是非常有效的，但是典型的技术环境与通常被引用的技术环境有很大的不同。我将在后面的文章中逐一介绍每一方面的细节，但是遗留问题、基础设施、交付周期和法规遵从性都是非常常见的挑战（在许多情况下相互交织在一起），如果您要成功地实现持续交付，就需要解决这些问题。最后，还必须了解，对于嵌入式产品开发组织来说，持续交付实现的最终目标通常与基于web或基于云技术的产品开发组织的最终目标有很大不同。1。对于嵌入式产品开发人员来说，典型的规范是，新产品和未来产品所依赖的现有IP和技术即使不是巨大的，也有大量的存在。在过去10年的行业工作中，我接触过数百个不同的嵌入式开发团队，我只能想到几个嵌入式开发团队，他们拥有从一张干净的纸开始设计、实现和组织机构这一遗产的实际后果是多方面的而且非常复杂——产品架构、大量代码库、团队组织、构建系统、测试环境。。。举个例子，我正在积极工作的一个嵌入式产品开发环境目前正在管理一个不断增长的遗留代码库130mloc，这个代码库已经存在了20年，在增长方面没有稳定和放缓的迹象——事实上，代码库在过去两年中增长了近50个！将这一传统重新融入到持续交付模式中并不容易，而且可能很昂贵，但几乎可以保证是值得的努力，尤其是如果您有一个长期的愿景，并打算让您的产品在未来保持竞争力。使遗留嵌入式系统的体系结构适应持续交付的模型是一项挑战，而且通常非常麻烦，因为产品体系结构是大多数产品开发团队如何组织自己及其工作的自然指导原则。通常情况下，平台、框架和应用程序组件的多层相互嵌套，导致复杂的单片代码库需要处理。我很少发现，系统的这些组件和部分可以单独处理，允许分开的交付和发布流——这几乎是成功和高效实现连续交付的必要条件。基础设施我没有硬数据来支持下面的说法，但是如果真的有这样的排名，我会说嵌入式产品开发人员很可能在"人均计算核心"和"人均测试环境成本"两个榜单中名列前茅。因此，与其他产品开发人员相比，可以公平地说，嵌入式开发人员在他们的开发基础设施方面有许多突出之处需要。满足嵌入式开发人员对计算基础设施永不满足的渴望和需求。构建嵌入式设备是一个复杂的项目，涉及硬件和软件组件，由大量的计算基础设施支持。无论您是否参与将系统的所有不同组件集成到将在设备上运行的映像中，或者如果您负责某些特定功能的实际开发，您几乎肯定会有一个永不满足的需求资源。更多具体来说，大多数嵌入式软件开发都是使用本地C/C++编程语言，易于长时间和CPU密集的构建过程。当今优化和加速构建时间的最明显和最常见的解决方案是投入大量的硬件来解决这个问题，允许在开发人员或构建服务器上的可用核心上并行地构建过程。作为一个有趣的参考例子，Android平台构建需要在一台机器上拥有48个以上的cpu核心，以最大限度地提高性能。满足这些计算基础设施负载需求的一种方法是购买和部署大量标准的大型现成服务器，但随着需要为任何嵌入式产品构建和管理的代码不断增长，您正在为自己准备一场代价高昂、永不停歇的与戈登·摩尔博士的比赛！（其他本地编程语言范例正在出现，它们有望克服构建时间方面的一些挑战，但这些语言中的任何一种要在嵌入式软件行业获得主流流行，还需要很多年甚至几十年的时间，随着您的持续交付实现规模和周期需要缩短，您的开发团队将需要更多的计算能力来适当地为软件构建、测试和分析工作的增加提供服务。如今，在保持规模经济性的同时，为其中一些工作负载提供必要的计算能力是一个复杂但相当容易理解的问题——集中开发云和专用后端高性能计算基础设施是满足您大规模高效软件构建需求的常用方法，分析与仿真器处理。管理物理目标测试自动化。嵌入式开发人员的另一个主要区别是如何有效地集成和管理基于物理目标的测试的自动化。对实际嵌入式硬件进行适当和自动化测试的需求迫在眉睫，我不希望这种需求会消失，因为我还没有听说任何嵌入式产品开发团队在不测试实际嵌入式硬件的情况下发布产品。如果您依赖于手动配置和部署物理目标，那么期望高效且始终可用的连续交付是不合理的环境。这些物理目标也是典型的定制硬件，非常昂贵，而且经常处于某种原型模式，因此容易变得脆弱。考虑到他们的成本和成熟度，我从来没有听说过一个产品开发团队有这么多的目标，所以最大限度地利用所拥有的目标是至关重要的。可能的解决方案和替代方案可避免如此依赖于实际的物理目标，例如复杂的全系统模拟器，可以在托管模拟中运行未更改的生产二进制文件环境在持续交付实现中自动化基于物理目标的测试的最后一个方面是实际的技术集成，以及如何正确地与被测系统（SUT）交互和协调。这个主题的细节对于所讨论的目标来说是非常具体的，它本身就值得发表自己的技术博客文章或论文，超出了本次讨论的范围。交付周期长的交付周期对任何产品开发团队的生产力都是有害的，并且要确保