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），这些团队具有较低的固有信任度，较高的延迟和较高的举证责任，证明提交的补丁程序确实不错。 分支曾经是一种计算量大的操作，后来变得如此便宜以至于成为现代软件开发的普遍方面。 同样， 拉取请求的出现促进了开源协作的崭新浪潮。

如果您进入任何成功的DevOps组织并四处看看，那么偏爱使用工具来促进跨团队或个人的高度协作开发就不足为奇了，否则这些团队或个人之间的耦合非常松散（因此，信任关系比协作者要小）在一个业务部门内工作）。 一个相当安全的假设是，将以某种方式使用Git，因为其他SCM解决方案（如cvs和subversion）不会促进在DevOps组织中普遍存在的泛组织协作。

许多DevOps从业者都非常重视共享。 我们分享我们的成功，我们分享我们的价值观，以及我们从失败中学到的东西，我们分享我们的指标，我们分享我们的代码。 而且我们以可以他人做出有意义贡献的方式共享我们的代码。 在没有开源的世界里，这是不切实际的。 在这个领域，最好的专有工具全都基于开放源代码工具，以及它们所支持的全球协作工作流中涌现的文化。

我们有没有DevOps的开源。 但是我认为如果没有开源，就不会有DevOps。 成功采用DevOps需要有强大的文化来为其提供支持，我相信最好的DevOps文化源于开源社区。

本文是由Greg Dekoenigsberg协调的Easy DevOps专栏的一部分。 通过open@opensource.com与我们联系，分享您的故事和建议，以及使工具运维，过程，文化，成功和光荣/不光彩的失败，以及有助于使DevOps实用的知识 。

翻译自: https://opensource.com/business/15/2/without-open-source-there-would-be-no-devops

devops 开源