早在 2008 年,在软件研发领域敏捷开发的国际会议上,已经有人开始反思研发流程中 Development 和 Operations 等角色之间的合作和效能问题。2009 年,在 O’Reilly 集团举办的“VelocityConference”会议上,两名 Flickr 员工(技术运营高级副总裁 John Allspaw 和工程总监 Paul Hammond)做了题为“10+ Deploys per Day: Dev and Ops Cooperationat Flickr”的演讲,从考古的角度来说这次演讲非常有价值和纪念意义,可以看做开创了我们现在所说的“DevOps”概念。其后,这个概念不断地被美国硅谷等地的一些大小互联网公司所采用和发展,创造出了一种新的软件研发思维模式和行动指南。 维基百科上,DevOps(Development 和 Operations 的组合词)是一种重视“软件开发人员(Dev)”和“IT 运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 现在,即使对 DevOps 有过了解甚至是已经在使用这种研发模式的人来说,也非常难以定义到底什么是 DevOps。有些观点认为,DevOps 是区别于传统的瀑布模式,基于敏捷模式,并将敏捷思想和实践从开发扩展到运维(也有激进的观点认为它完全不同于这两种研发模式),是一种新的思维模式和行动方法。它的目的是为了提升整个研发效能,进行更便捷、更快速、更可靠的交付,从而提高产品竞争优势。DevOps 模糊了以往研发模式中开发、测试、运维等岗位和角色的界限,加强了他们之间的协作,通过流水线和一系列的自动化机制、成熟可伸缩的基础设施(如云)等,使开发人员获得更高的效能,可以更加频繁且快速的将代码变为产品,并从这种快速中获得持续不断的反馈和验证,也获得更高的可靠性。如下图示经常会被用于对 DevOps 的示意。
瀑布模式 VS 敏捷模式 VS DevOps
让我们对比下瀑布模式、敏捷模式、DevOps 三种方式,可能更利于理解他们在表面上的变化。 实际上,上述对比只能说明表面上的变化。为了能够达到 DevOps 的目标:更便捷更频繁地进行更可靠的交付,除了思维模式以外,DevOps 需要一些技术和工具来支撑,也是得益于一些基础设施和工具等的发展和成熟,越来越多的公司才得以来践行 DevOps。