通过Eva Skoglund

“Devops对嵌入式系统的意思是什么，我应该关心吗？”好吧，你应该 - 至少如果你根据任何敏捷原则工作。

开发和运营的合并，德沃斯在IT世界中很热;仍然如此热，没有普遍接受的定义。但是，当您为嵌入系统中嵌入的软件的DevOps主题时，响应更像是，“真的？怎么可能适用？“毕竟，对于许多嵌入式系统而言，没有“ops”，因为它在IT世界中已知。我们构建一个设备，或者其他人运作的系统。构建系统的人很少参与系统的实际操作。

问题是，DevOps是关于组织的(在其他方面)，而敏捷是关于方法的。您使用的方法将最终影响您的组织。因此，我认为敏捷和DevOps属于同一条进化道路。我们在交叉学科的工程团队中所看到的就是证明。

按照任何一种敏捷原则工作过一段时间的团队都倾向于将自己重新组织成跨学科或跨功能的团队(见此)Nicholas Muldoon的博客文章．为了保持高速度并将交付时间降至最低，您需要减少团队之间的各种移交和同步。因此，设计人员、测试人员、开发人员和集成人员合并成一个跨职能团队，他们可以快速解决问题，拥有快速的反馈循环，并保持高度的自治。跨功能团队对某个功能或子系统负有端到端责任。现在，您不必将任务或责任移交给另一个团队(甚至可能是另一个组织)，而是在您自己的团队中进行讨论和工作。如果你和团队成员关系密切，可以快速解决即将出现的问题，并讨论解决方案，你就能工作得更快。

下图说明了功能和跨功能组织之间的差异。这与尼古拉斯Muldoon的博客文章（上面引用的博客文章（上文称为）非常相似，但修改为仅限于工程组织的一点。

端到端责任还包括交付责任。如果您的持续集成系统已经演变成持续交付系统(参见我前面的文章)帖子关于持续交付和部署，当您的代码sprint通过了所有级别集成测试的考验后，就达到了产品质量，您的跨功能团队也可以负责代码sprint的交付。现在，我们有了更大的端到端的责任，从设计到交付。

这样，我们就更接近“行动”方面了。嵌入式系统的“操作”是什么?这里有好几层操作。我们可以把它看作实际终端设备的操作(路由器、网关、飞行引擎、血泵、多功能打印机……)，在这种情况下，操作是由系统的用户来处理的(例如，护士操作透析机)。我们也可以把它看作是制造商的操作，比如透析机。他们制造机器，为机器生产硬件和软件。这里的操作可能意味着将嵌入式软件部署到产品中。今天这可能意味着在硬件上闪烁软件，在未来可能意味着通过互联网更新软件。另外一个层面的操作可能与这些公司成为制造这些机器的公司的软硬件供应商有关。例如，有人构建包含在高端服务器中的固态磁盘，或公司构建路由器中使用的网络软件。 With the exception of the first example, the user of the device (the nurse), my point is that all companies have some sort of operations – we deliver systems, hardware and/or software, to our customers, and as such we have our own operations that we manage. We have a support organization, we have a delivery organization, maybe a service organization, etc. All of this is operations. While a cross-functional team sometimes only refers to a team within the engineering organization, what stops the organizational merge or change from being limited within engineering only? For example, wouldn’t support be more efficient if it was closer to an end-to-end responsibility flow, and maybe even integrated with the development team?

当你把责任包括进去的时候交货在跨职能团队的组织中，您需要按照DevOps的建议进行组织变革。在进行持续交付和部署的过程中，方法变更将影响您如何构建组织。

敏捷实践已经成功地提高了工程组织的生产力，使工程不再是进入市场和交付的瓶颈。但瓶颈仍然存在，他们只是转移到了组织的其他地方。正如Gartner在2015年3月12日的报告《DevOps的原则和实践》中所说

“敏捷(和精益)方法已经显著改善了许多企业的开发过程。然而，没有将类似的概念应用到下游组(如操作)，瓶颈只是被移到了右边。”

我的观点是，在IT和网络世界中，“ops”可能只指IT系统，因此像NetFlix或Facebook这样的公司谈论DevOps是有意义的。但是，每个公司都有自己的操作方面，即使你提供的是嵌入软件的复杂电子系统。我们仍然向客户交付产品，这也是DevOps的目标。

自从我与Simics和模拟一起工作以来，我一直在思考模拟如何在DevOps之旅中有所帮助。我们已经很清楚Simics如何帮助采用敏捷实践(参见我们的敏捷的视频］．DevOps术语强调协作，沟通和自动化．这些是您通过使用Simics之类的模拟技术所获得的关键好处。另外，我认为Gartner在之前提到的DevOps报告中指出的一个关键观察:

“许多Devops的最终目标是能够连续交付（进入暂存），如果不是连续部署（进入生产），每个源代码存储库更改”。

暂存区域是您在继续部署之前测试和查看软件的位置，它类似于暂存站点的概念[请参阅http://en.wikipedia.org/wiki/staging_site]。对于嵌入式系统，软件部署自然地在物理目标上。但前一步怎么样？在功能良好的连续集成（CI）系统中，您有许多级别的CI-LOOPS，如果这些循环中的每一个只能基于物理目标硬件，您需要很多扩展你的测试(见Jakob Engblom的博客//www.kuechentipps.com/wind_river_blog/2014/09/continuous-integration-with-simics.html)。基本上，每个CI循环都可以看作是一个逐渐构建的系统，在这里您可以测试软件的质量。为了扩展测试，并尽可能地实现自动化，模拟就是一个很好的选择。在您的代码准备好部署到物理硬件之前，您可以让它准备好交付到一个暂存区，即一个模拟的系统。请看下面的图片。

那么，嵌入式系统的“操作”是什么?我们能说DevOps是相关的吗?每个公司都有运营的一面，如果你从事的是用嵌入式软件构建和交付复杂电子系统的业务，你将看到市场的变化，要求更快地交付系统和软件。DevOps就是要加速这一点。所以，是的，DevOps与嵌入式系统高度相关。我们刚刚看到它的开始，通过敏捷实践被采用。我们知道前面还有许多挑战，因为毕竟，我们所建造的，是rocket science But I think that with simulation, we can get a little closer to the vision of DevOps for software that is embedded in complex electronics systems.