相反，这是一个系统性的工程，你应该使用合适的工具和技术来完成不同的任务。

所有的一切都是为了流程

具体是什么流程并不重要，只要它可以简化应用程序的部署或者自动化测试，让你的生活更轻松，那这就是DevOps的全部内容。

事实上，如果你的流程不能手动完成(针对较小的流程)，你可能需要重新定义你的流程。

好了，让我们举一个真实的例子来更好地理解“流程”。

一个真实的DevOps例子

我们举一个，在云虚拟机上部署Nodejs应用程序的例子。

流程

我们的流程如下：

从源代码开始(Start with the source code)：只要我们能访问源代码，我们就可以在任何地方运行我们的代码。

构建制品(Build an Artifact)：然后我们打包源代码来构建一个制品。如果是Java语言，那么JAR文件就是我们的制品。但在我们Nodejs的例子中，源代码本身就是要发布的制品。

发布到制品仓库(Publish to an Artifact Repository)：接下来，我们将制品推送到制品仓库。然后我们的虚拟机就可以从制品仓库中提取制品。我们可以直接使用Github作为我们的制品仓库，因为我们的源代码即制品。

拉取并运行应用程序(Pull and run your app)：最后，我们将制品拉取到虚拟机上，并通过指令npm start来启动Nodejs进程。

“可重复”的重复性

让我问你一个问题。你喜欢以下哪一个?

一个在60%的时间内，能正常工作的自动化部署管道;

一个无聊的shell脚本，但是每次执行都能完成任务。

如果你曾经在半夜处理过生产故障，那么你将选择shell脚本。

原因很简单。可靠性远比自动化程度更重要。换句话说，一个DevOps流程必须能够在每次运行时产生一致的结果。

使我们的过程可重复

以我们的shell脚本为例。目前，我们的shell脚本依赖于安装在虚拟机上的Node.js。

如果没有在虚拟机上安装Node.js，会发生什么?一个错误的Node.js版本足以使我们的应用程序不能正常运行。当我们需要在虚拟机上安装多种语言运行时时，情况只会变得更糟。

一个简单的解决方案是将Node.js运行时与我们的源代码一起归档到zip文件中。然后可以将zip文件发送到虚拟机。这样，虚拟机就可以使用zip文件中的本地Node.js运行时来运行我们的应用程序。