现在很多人都在困惑持续交付和DevOps到底是什么关系，有什么区别，或许你也感觉傻傻分不清楚。那么今天，我就来和你聊聊持续交付和DevOps，以及它们到底是什么关系。

持续交付是什么?

我在专栏的第一篇文章中，已经跟你很详细地分享了持续交付是什么，为了加深你的印象，并与DevOps形成对比，我在这里再从另外一个角度给你总结一下:

持续交付是，提升软件交付速率的一套工程方法和一系列最佳实践的集合。

它的关注点可以概括为:持续集成构建、测试自动化和部署流水线。

那么，DevOps又是什么呢?其实一直以来，学术界、工业界都对DevOps没有明确的定义，所以造成了大家对它的看法也是众说纷纭，也难免片面。

在我给出我个人的认识之前，我先给你讲讲DevOps是怎么被发明的吧

DevOps的诞生

DevOps的故事，要从一个叫帕特里克·德博伊斯(PatrickDebois)的IT咨询师讲起。2007年，帕特里克参与了一个政府下属部门的大型数据中心迁移的项目。

在这个项目中，帕特里克发现开发团队(Dev)和运维团队(Ops)的工作方式和思维方式有巨大的差异:

Dev的工作是，为软件增加新功能和修复缺陷，这要通过频繁的变更来达到;
Ops的工作是，保证系统的高稳定性和高性能，这代表着变更越少越不容易出错。

因此，Dev和Ops长久以来，都处于对立和矛盾的状态。

2009年6月23日，Flickr公司的运维部门经理约翰·阿斯帕尔瓦(JohnAllspaw)和工程师保罗·哈蒙德在Velocity大会上做了一个轰动世界的演讲:《每天部署10次以上:Flickr公司的Dev与Ops的合作》(10+Deploys Per Day:Devand Ops Cooperation at Flickr)。

这个演讲中提出了DevOps的核心观点:Dev和Ops的矛盾可以通过技术升级和文化构建来解决，这标志着DevOps的诞生。

帕特里克也在网上看到了这个演讲，并且十分兴奋，因为这就是长久以来他所想解决的问题。于是，他开始筹备自己的Velocity大会。

2009年10月，帕特里克的Velocitv大会在比利时顺利召开，他把会议命名为DevOpsDays。他本来想用DOD作为DevOpsDays的缩写，以提醒自己“死在交付上”(DeadOn Delivery)，但不知什么原因，他最后没有这么做。

这届大会出人意料的成功，许多开发工程师和运维工程师参加了这次大会，甚至还有各种IT管理人员参加。人们开始在Twitter上大量讨论DevOpsDays的内容。

由于Twitter对内容长度的限制是140个字符，所以大家在Twitter上讨论时去掉了“Days”，只保留了“DevOps”。于是，DevOps这个名称正式诞生。

持续交付的姗姗来迟

在DevOps的这段编年史里，持续交付又在哪里呢?

2006年，杰斯·亨布尔(JezHumble)，克里斯·里德(ChrisRead)和丹·诺斯(Dan North)在Agile大会上发表了一篇名为《部署生产线》(DeploymentProductionLine)的文章，这也是第一篇描述持续部署核心内容的会议文章。

在后面的三年里，又有一系列“持续部署”的文章被发表。2009年，这一些系列的文章被编成为了一本叫作《持续交付:发布可靠软件的系统方法》的书，这一年也正是帕特里克举办 DevOpsDays的那一年。

2010年，《持续交付:发布可靠软件的系统方法》的作者之一杰斯参加了第二届的DevOpsDays，并做了关于“持续交付”的演讲，在这一年“DevOps”与“持续交付”终于有了交集。

从本质上说，帕特里克最初遇到的问题，在《持续交付:发布可靠软件的系统方法》一书中找到了最佳实践。如果这本书可以早两年问世，或许今天就不会有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的关系:

1.DevOps的本质其实是一种鼓励协作的研发文化;

2.持续交付与 DevOps 所追求的最终目标是一致的，即快速向用户交付高质量的软件产品

3.DevOps的概念比持续交付更宽泛，是持续交付的继续延伸;

4.持续交付更专注于技术与实践，是DevOps的工具及技术实现