没有开源，就不会有 DevOps

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

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

这种模糊性助长了持续的困惑，并为一些投机分子滥用“DevOps”一词以谋取不正当利益创造了机会。这主要是因为一些opportunists只想用“DevOps”这个词来向你推销你本来不会关注的工具或服务。

事实上，没有开源，就不会有 DevOps。 有一连串的事件，我敢说是一个技术和理念的“完美风暴”，它们的崛起不可避免地导致了 DevOps 或类似事物的出现。

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

但更重要的是，开源是技术发展的同时，文化发展的孵化器。 Eric S. Raymond 的颠覆性文章大教堂与集市一夜之间向世界揭示了一个在全球范围内扩展软件项目的框架。 许多构成 DevOps 运动基础的价值观都存在，即使在开源运动的早期阶段也是如此。

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

不容忽视的是 Linus Torvalds 对开源社区的最大贡献。 我不是在谈论 Linux，我指的是 Git。 Git 从高度协作的开发团队的角度重新构想了源代码管理 (SCM)，这些团队的固有信任度较低、延迟较高，并且提交的补丁确实有效的举证责任较高。 分支曾经是一项计算成本高昂的操作，现在变得非常便宜，以至于成为现代软件开发的普遍方面。 同样，pull request 的出现促进了全新的开源协作浪潮。

如果您进入任何成功的 DevOps 组织并四处看看，不应该感到惊讶的是，工具的选择有利于跨团队或个人进行高度协作的开发，否则这些团队或个人可能会非常松散地耦合（因此，与在一个业务部门内工作的协作者相比，信任关系较弱）。 可以肯定的是，Git 将以某种方式被使用，因为其他 SCM 解决方案（如 cvs 和 subversion）不支持 DevOps 组织中普遍存在的这种全组织协作。

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

我们曾经拥有没有 DevOps 的开源。 但是如果没有开源，我认为就不会有 DevOps。 成功采用 DevOps 需要强大的文化来支持它，并且我相信最好的 DevOps 文化都扎根于开源社区。

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