没有开源，就不会有 DevOps

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

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

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

事实上，如果没有开源，就不会有 DevOps。有一连串的事件，我敢说是一场技术和理念的“完美风暴”兴起，这使得 DevOps 或类似的东西的兴起成为必然。

开源项目的兴起为我们提供了免费的操作系统，这使得现代动态 Web 在经济上成为可能。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 变得实用，以及来自你的经验的工具、流程、文化、成功和光荣/不光荣的失败。.