通过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循环都可以看作是一个逐渐构建的系统，在这里您可以测试软件的质量。为了扩展测试，并尽可能地实现自动化，模拟就是一个很好的选择。在您的代码准备好部署到物理硬件之前，您可以让它准备好交付到一个暂存区，即一个模拟的系统。请看下面的图片。

那么，嵌入式系统的“ops”是什么？我们可以声称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.