现在很多人都在困惑持续交付和DevOps到底是什么关系,有什么区别,或许你也感觉傻傻分不清楚。那么今天,我就来和你聊聊持续交付和DevOps,以及它们到底是什么关系。
我在专栏的第一篇文章中,已经跟你很详细地分享了持续交付是什么,为了加深你的印象,并与DevOps形成对比,我在这里再从另外一个角度给你总结一下:
持续交付是,提升软件交付速率的一套工程方法和一系列最佳实践的集合。
它的关注点可以概括为:持续集成构建、测试自动化和部署流水线。
那么,DevOps又是什么呢?其实一直以来,学术界、工业界都对DevOps没有明确的定义,所以造成了大家对它的看法也是众说纷纭,也难免片面。
在我给出我个人的认识之前,我先给你讲讲DevOps是怎么被发明的吧。
DevOps的故事,要从一个叫帕特里克 · 德博伊斯(Patrick Debois)的IT咨询师讲起。2007年,帕特里克参与了一个政府下属部门的大型数据中心迁移的项目。
在这个项目中,帕特里克发现开发团队(Dev)和运维团队(Ops)的工作方式和思维方式有巨大的差异:
因此,Dev和Ops长久以来,都处于对立和矛盾的状态。
2009年6月23日,Flickr公司的运维部门经理约翰 · 阿斯帕尔瓦(John Allspaw)和工程师保罗 · 哈蒙德在Velocity 大会上做了一个轰动世界的演讲:《每天部署10次以上:Flickr公司的Dev与Ops的合作》(10+ Deploys Per Day: Dev and Ops Cooperation at Flickr)。
这个演讲中提出了DevOps的核心观点:Dev和Ops的矛盾可以通过技术升级和文化构建来解决,这标志着DevOps的诞生。
帕特里克也在网上看到了这个演讲,并且十分兴奋,因为这就是长久以来他所想解决的问题。于是,他开始筹备自己的 Velocity 大会。
2009年10月,帕特里克的Velocity大会在比利时顺利召开,他把会议命名为DevOpsDays。他本来想用 DOD作为 DevOpsDays 的缩写,以提醒自己“死在交付上”(Dead On Delivery),但不知什么原因,他最后没有这么做。
这届大会出人意料的成功,许多开发工程师和运维工程师参加了这次大会,甚至还有各种IT管理人员参加。人们开始在 Twitter上大量讨论DevOpsDays的内容。
由于Twitter对内容长度的限制是140个字符,所以大家在Twitter上讨论时去掉了“Days”,只保留了 “DevOps”。于是, DevOps这个名称正式诞生。
在DevOps的这段编年史里,持续交付又在哪里呢?
2006 年,杰斯 · 亨布尔(Jez Humble),克里斯 · 里德(Chris Read)和丹 · 诺斯(Dan North)在 Agile 大会上发表了一篇名为《部署生产线》(Deployment Production Line)的文章,这也是第一篇描述持续部署核心内容的会议文章。
在后面的三年里,又有一系列“持续部署”的文章被发表。2009年,这一些系列的文章被编成为了一本叫作《持续交付:发布可靠软件的系统方法》的书,这一年也正是帕特里克举办DevOpsDays的那一年。
2010 年,《持续交付:发布可靠软件的系统方法》的作者之一杰斯参加了第二届的 DevOpsDays,并做了 关于“持续交付”的演讲,在这一年“DevOps”与“持续交付”终于有了交集。
从本质上说,帕特里克最初遇到的问题,在《持续交付:发布可靠软件的系统方法》一书中找到了最佳实践。如果这本书可以早两年问世,或许今天就不会有DevOps了。
然而,DevOps 的概念一直在向外延伸,包括了:运营和用户,以及快速、良好、及时的反馈机制等内容,已经超出了“持续交付”本身所涵盖的范畴。而持续交付则一直被视作DevOps的核心实践之一被广泛谈及。
这么看来,持续交付真是打了一个大盹儿。
DevOps这几年一直在不断地演化,那么它到底是什么呢?
目前,人们对DevOps的看法,可以大致概括为DevOps是一组技术,一个职能、一种文化,和一种组织架构四种。
第一,DevOps是一组技术,包括:自动化运维、持续交付、高频部署、Docker等内容。
但是,如果你仅仅将DevOps认为是一组技术的集合的话,就有一些片面。任何技术都是为了解决某些问题而被创造出来的。比如Docker,就是为了解决 DevOps 所提倡的“基础设施即代码”这个问题,而被创造出来的。
从这个角度来看的话,DevOps的范畴应该远远大于一组技术了。
其实,DevOps是一组技术这个观点,还是只站在了工程师角度去思考问题而得出的结论。虽然“DevOps”中“Dev”和“Ops”这两个角色都是工程师,但是其本质还是希望跳出工程师的惯性思维来看待问题。
第二,DevOps是一个职能,这也是我在各个场合最常听到的观点。
你的公司有没有或者正准备成立一个叫作DevOps的部门,并将这个部门的工程师命名为DevOps工程师?至少在各大招聘网站上,是随处可见这样的职位,而招聘要求往往就是:会Ops技能的Dev,或者会Dev技能的Ops;或者干脆叫全栈工程师。
“DevOps是一个职能”这个观点,源于设施的日趋完善,云服务的流行,以及各类开源工具的广泛使用,使传统Ops的工作重心发生了变化,使企业产生了不再需要Ops的错觉。
但这个观点也是错误的,原因就是忽略了Dev与Ops本质上是不同的,也就是他们掌握的技能是不同。
虽然在DevOps看来,Dev和Ops的最终目标是一致的,都是为了快速向客户提供高质量的产品,但其达到目标的手段和方法是不一样的。比如,Ops 往往需要更多的在线处理问题的经验,而这未必是Dev所具备的。
所以,简单地把DevOps看做是一个职能,是一个彻底错误的观点。
第三,DevOps是一种文化,推倒Dev与Ops之间的阻碍墙。
DevOps是通过充分的合作解决责任模糊、相互推诿的问题和矛盾。在著名的演讲《每天部署10次以上:Flickr公司的Dev与Ops的合作》 中,就明确的指出工具和文化是他们成功的原因。
其实,DevOps通常想要告诉我们的是:什么行为是值得被鼓励的,而什么行为需要被惩罚。通过这样的方法,DevOps可以促使我们形成良好的做事习惯,也就是DevOps文化。
所以,我们可以发现引入DevOps的组织,其实都是希望塑造这样的一种:信任、合作、沟通、学习、分享、共担等鼓励协作的文化。
第四,DevOps是一种组织架构,将Dev和Ops置于一个团队内,一同工作,同化目标,以达到 DevOps文化地彻底贯彻。
这看起来确实没有什么问题,而且敏捷团队往往都是这么去做的。但是,从另一方面来看,Ops作为公司的公共研发资源,往往与Dev的配比是不成比例。所以,虽然我们希望每一个敏捷团队都有Ops,但这可能是一种奢求。
但是,敏捷团队也说了,不一定是要有一个专职Ops人员,只要有负担这个角色职责的成员存在即可。这当然也讲得通,但可能真正的执行效果就没有DevOps所设想的那么好了。
所以,DevOps是一种组织架构,这种说法,也对也不对,主要视组织的具体情况而定。
今天,我和你一起回顾了DevOps产生的历程。同时,也顺便带你回顾了一下爱打盹儿的持续交付。我希望通过这篇文章,你可以理清持续交付和DevOps的关系:
DevOps的本质其实是一种鼓励协作的研发文化;
持续交付与 DevOps 所追求的最终目标是一致的,即快速向用户交付高质量的软件产品;
DevOps的概念比持续交付更宽泛,是持续交付的继续延伸;
持续交付更专注于技术与实践,是 DevOps 的工具及技术实现。
DevOps大潮袭来,企业是不是真的就不需要Ops这个岗位了呢?
欢迎你给我留言。