今天，许多嵌入式开发人员和团队正在解决的一个问题是如何管理他们的CI/CD管道。持续集成(CI)很有意义，因为它专注于构建、测试和验证嵌入式软件。但是持续部署(CD)呢？

 

一开始持续部署嵌入式软件听起来很棒，但是你真的想持续向你的客户部署新软件吗？如果你正在构建汽车电子控制单元(ECU)、医疗设备，甚至微波炉或家用电器，你的客户真的希望频繁更新吗？

 

这引发一个有趣的问题：嵌入式产品的持续交付有意义吗？

 

持续部署的目的

CD是一种软件开发实践，其中代码更改被自动构建、测试并部署到生产中，而无需人工干预。这种方法扩展到了CI之外，在CI中，更改会被自动测试，但不一定会被部署。CD为团队提供了诸多好处，例如：

l 加速上市时间

l 一致可靠的部署

l 更快的反馈循环

对于软件行业的许多人来说，持续部署已经改变了游戏规则，例如对于移动和web应用程序。当然，在嵌入式产品中，持续交付很有意义，但是那些只想每季度或每年提供更新的系统怎么办？

 

嵌入式中的持续交付应该是什么样的？

连续交付通常被视为向客户交付新软件。你可能会把顾客看作是在现场购买和使用你的产品的人。然而，这可能是对客户的狭隘看法。内部人员或团队经常使用你创建的软件工件，并使用它们来验证产品是否工作，是否满足整体的项目目标和需求。如果你将这些队友视为你软件的客户，那么持续交付和你如何定义你的管道可能会改变。

 

例如，作为一个软件团队，你可能会定义一个类似于下面图1的连续交付管道：

在这个管道中，你可以看到我们定义了几个作业。如果CI渠道成功，我们将有一个创建最终交付包的包作业，然后有一个将所有材料集中在一起进行发布的发布作业。从那里，我们有一个体现持续部署的生产开发工作。生产开发作业将被部署到一个内部测试平台，开发人员可以用它来验证构建。

从那里，发布可以由质量保证团队批准。一旦通过审批流程，分阶段发布可能会进入现场生产。它们也可能是对每季度或每年在现场推出的更大版本的逐步验证。

 

结论 

对于嵌入式软件开发人员和团队来说，持续交付是一个必不可少的工具。虽然向客户部署新软件的传统方法可能没有意义，但是部署到生产测试环境中就有意义了。生产测试环境允许开发人员和质量保证人员在向客户推出新固件之前验证一切正常。虽然这可能不完全符合持续交付的精神，但它非常适合许多嵌入式产品团队。那么，持续交付对于嵌入式产品有意义吗？

 

我想我们可以肯定地说，确实如此；这取决于我们的“持续”时间框架，以及这些版本是部署给内部客户还是外部客户。持续部署有很多好处；即使你没有自动将新固件推送到现场，它仍然可以在内部进行验证。