没有开源，就不会有 DevOps

如果我们要搞 DevOps，就必须放弃开源。对吗？等等，我们是敏捷团队，所以我们也要放弃敏捷。对吗？

在过去的五年左右，我与很多人交流过，他们对“搞 DevOps”意味着什么感到困惑，并且显然担心为了采用 DevOps 而不得不放弃其他已经证明其价值的东西。坏消息是，在 DevOps 社区发展的早期阶段，我们没有很好地明确 DevOps 是什么，不是什么。

这种模糊性助长了持续的困惑，并为那些可疑地滥用“DevOps”一词以牟取暴利的人提供了机会。这主要来自那些只想利用“DevOps”这个词来向您推销他们的工具或服务，否则您根本不会注意的投机分子和无赖。

事实上，没有开源，就不会有 DevOps。一系列事件，我甚至可以说是一场技术和理念兴起的“完美风暴”，使得 DevOps 或类似事物的兴起成为必然。

开源项目兴起，为我们提供了免费的操作系统，使现代动态网络在经济上成为可能。Linux 和 GNU 功不可没。当然，中间件、关系型（和非关系型）数据库以及无数编程语言通过开源社区兴起，为 DevOps 的成功提供了必要的技术支架。

但更重要的是，开源是随着技术兴起的文化发展的孵化器。Eric S. Raymond 的颠覆性文章《大教堂与集市》一夜之间向世界揭示了一个在全球范围内扩展软件项目的框架。许多构成 DevOps 运动基础的价值观，甚至在开源运动的早期阶段就已经存在。

随着开源的成熟，工具催生了更多的工具，进而催生了快速开发框架、持续集成工具和工作流程、单元测试框架等等，我们开始看到非常复杂的软件应用程序以惊人的速度建立并交付给客户。开源解决方案兴起，用虚拟机取代物理机，用虚拟机取代云实例，用云实例取代容器。IaaS、SaaS 和 PaaS 需要 DevOps 的出现才能取得成功。

不容忽视的是 Linus Torvald 对开源社区的最大贡献。我不是在说 Linux——我指的是 Git。Git 从高度协作的开发团队的角度重新构想了源代码管理 (SCM)，这些团队的内在信任度较低、延迟较高，并且对提交的补丁确实是好的证明负担更高。分支曾经是一项计算成本很高的操作，现在变得非常廉价，以至于成为现代软件开发中普遍存在的一个方面。同样，pull request 的出现促进了开源协作的新浪潮。

如果你进入任何成功的 DevOps 组织并环顾四周，那么工具受到青睐以促进跨团队或个人的高度协作开发应该不足为奇，这些团队或个人可能非常松散地耦合（因此，与在一个业务部门内工作的协作者相比，信任关系较弱）。可以肯定地假设 Git 将以某种方式被使用，因为其他 SCM 解决方案（如 cvs 和 subversion）不利于在 DevOps 组织中普遍存在的跨组织协作。

许多 DevOps 从业者非常重视分享。我们分享我们的成功，我们分享我们的价值观以及我们从失败中吸取的教训，我们分享我们的指标，并且我们分享我们的代码。我们分享代码的方式是其他人可以有意义地贡献。这在没有开源的世界中是不切实际的。该领域中最好的专有工具都基于开源工具，以及从它们支持的全球协作工作流程中产生的文化。

我们有过没有 DevOps 的开源。但是，如果没有开源，我认为就不会有 DevOps。成功采用 DevOps 需要强大的文化来支持它，而且我认为最好的 DevOps 文化根植于开源社区。

本文是 Greg Dekoenigsberg 协调的“Easy DevOps”专栏的一部分。请通过 open@opensource.com 联系我们，分享您的故事和建议，这些故事和建议有助于使 DevOps 变得实用——以及您经验中的工具、流程、文化、成功和光荣/不光荣的失败。.