早期的DevOps：联合开发和运营

在早期，DevOps是非常简单和直接的。当时的想法是，如果开发人员和IT运营工程师能够更好的沟通，了解彼此的观点，出现问题的时候不再相互指责，那么软件部署将会更加顺畅。

在此期间，DevOps很少涉及到特定的工具或方法。DevOps团队所支持的大多数工具（例如CI服务器）都是敏捷运维的一部分，而敏捷运维比DevOps早了好几年。

因此，一开始DevOps规定了一个目标——在开发人员与IT Ops之间进行更好的交流，但实际上并没有提供任何工具或流程来帮助实现该目标。如何“执行DevOps”取决于用户。

容器和DevOps

这种情况一直持续到2013年，直到Docker容器的公开可用转变了这种状况。

Docker并不是第一个容器化平台。实际上，容器技术可以追溯到几十年前。但是可以说，Docker是幸运的，因为它正好出现在DevOps倡导者寻找一种可以将他们的理念付诸实践之时。

这就是Docker（以及后来出现的其他容器平台，如Kubernetes）所做的，它提供了一种可在开发和生产环境中使用的应用程序部署格式。通过这种方式，Docker容器简化了开发人员与IT工程师之间的协作，从而促进了DevOps的核心目标。

这并不是说容器已经成为执行DevOps的唯一技术解决方案，除了促进实现DevOps的目标外，还有许多其他的原因促使我们使用容器。

尽管如此，DevOps容器在20世纪20年代前期仍扮演了重要的角色，它帮助DevOps从业人员构建了一个实际的工具集，并将DevOps从理念转为现实。

超越DevOps：“一切Ops”的兴起

到20世纪20年代中期，DevOps的发展发生了另一个重大的变化：不仅是开发人员和IT工程师，软件交付过程中的其他利益相关者（如软件测试人员和安全专家），也被纳入了DevOps的阵营。

换句话说，DevOps的目标变成了无缝协作，不仅是在开发人员与IT之间，还包括测试团队、安全团队等等。

到2016年，这一扩展已经完成，New Relic 宣布“everything Ops”的兴起，并确定了DevOps的十几个分支，其中大多数旨在将这些原理扩展到其他领域（从数据、安全到市场营销）。其他定义将DevOps扩展到整个组织的趋势称为“ DevOps 2.0”。

“连续”万物的时代

在过去的几年中，每个与DevOps有关的进程都被认为是“连续的”。

关于“连续”的定义并不总是完全相同。但是总的来说，当人们在DevOps上下文中谈论流程是连续的时候，他们指的是流程应该发生在软件交付的所有阶段。例如，不应该只在某一点测试软件，而应该在整个生产过程中一直进行测试。同样，不是只执行一次安全扫描，而是连续地执行。

这种对“连续性”的痴迷使某些人把这个时代称为“连续的一切”。有时，这个说法过于偏颇，因为并不是每个过程都需要完全连续。此外，很少有进程是连续的，因为它们在持续不断地活动，没有延迟。如果不是连续的话，其真正的目标是使流程全面且可预测。

DevOps的未来发展

DevOps意味着什么？接下来又该怎样发展？

有人认为，之后机器学习和AI将会结合到DevOps的实践中。毕竟，DevOps是关于无缝流程的，而AI支持的决策可以通过消除人工干预使流程更流畅。（当然，这也可能使他们面临更大的风险，但团队可能会发现这种权衡是值得的。）

除此之外，DevOps和云将会有更大程度的交集。令人惊讶的是，在DevOps社区中，并没有对云（或所谓的云原生技术）有特别的关注。当然，许多DevOps从业人员都使用云，但是许多面向DevOps的工具（例如CI服务器和容器）并没有绑定到云上，它们可以在本地或云中运行。几年后，DevOps将主要集中在基于云的工具上。