如今，许多嵌入式开发人员和团队正在解决的一个问题是如何管理他们的CI/CD pipeline(流水线)。持续集成(CI)非常有意义，因为它侧重于嵌入式软件的构建、测试和验证。但是持续部署(CD)呢？
持续部署嵌入式软件一开始听起来不错，但您真的想持续向客户部署新软件吗？如果您正在制造汽车电控单元(ECU)、医疗设备，甚至微波炉或家用电器，您的客户真的需要频繁更新吗？
这就给一些团队提出了一个有趣的问题：嵌入式产品的持续交付是否有意义？
CD是一种软件开发实践，其中代码更改会自动构建、测试并部署到生产中，无需人工干预。这种方法超出了CI的范畴，在CI中，更改会自动测试，但不一定会部署。CD为团队带来了以下好处：
对于软件行业的许多人来说，持续部署已经改变了游戏规则，例如移动和Web应用。当然，在某些嵌入式产品中，持续交付非常有意义，但对于那些只想每季度或每年提供更新的系统又如何呢？
持续交付通常被视为向客户交付新软件。您可能认为客户就是那些在现场购买和使用您产品的人。然而，这可能是一种狭隘的客户观。内部人员或团队也经常会使用您创建的软件工件来验证产品是否能正常运行，是否符合项目的总体目标和要求。如果您将这些团队成员视为您软件的客户，那么持续交付以及您定义pipeline的方式可能会发生变化。
例如，作为一个软件团队，您可以定义一个类似于下图的持续交付pipeline：
在此pipeline中，您可以看到我们定义了多个作业。如果CI pipeline成功，我们就会有一个打包作业来创建最终交付包，然后是一个发布作业，将所有材料整合在一起进行发布。之后我们还有一个体现持续部署的生产开发作业。生产开发作业将部署到内部测试台，然后开发人员可以使用该测试台来验证构建。
在此基础上，发布可以分阶段进行，供质量保证团队审批。分阶段发布的版本一旦通过审批流程，就可以在现场投入生产。它们也可能是对每季度或每年推出的更大版本的按阶段地验证。
持续交付可以成为嵌入式软件开发人员和团队的重要工具。虽然向客户部署新软件的传统方法可能没有意义，但部署到生产测试环境却很有意义。生产测试环境允许开发人员和质量保证人员在向客户推送新固件之前验证一切正常。虽然这可能并不完全符合持续交付的精神，但它对许多嵌入式产品团队来说非常适合。那么，持续交付对于嵌入式产品有意义吗？
我想我们可以肯定地说，当然！这取决于我们“持续”的时间框架以及这些版本是部署给内部还是外部客户。持续部署有很多好处，即使您没有自动将新固件推送到现场，仍然可以在内部推送它以进行验证。
(原文刊登于EDN姊妹网站Embedded，参考链接：Does continuous delivery for embedded products make sense?，由Ricardo Xie编译。)
最前沿的电子设计资讯
