没有开源，就不会有 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 协调的“简单 DevOps”专栏的一部分。请通过 open@opensource.com 联系我们，分享您的故事和建议，这些故事和建议有助于使 DevOps 变得实用——以及来自您经验的工具、流程、文化、成功和光荣/不光荣的失败。.