DevOps和持续交付

小编说：DevOps 领域在近年来变得流行而普遍。由开发（developers）和运维（operations）组成的“共同协作”，归根结底，就是为了提高产品质量。
本文选自《DevOps实践》，您将了解如何在大规模敏捷背景和不同的敏捷开发周期中使用DevOps。

DevOps简介
在定义上，DevOps是一个涵盖着几条线的领域。它既非常实用又贴近实践。但与此同时，你需要了解的不仅有技术背景，还有非技术的文化方面。
DevOps由开发（developments）和运维（operations）两个单词组成。这个双关语已经揭示了DevOps的本意，那就是鼓励不同的软件开发部门共同协作。
DevOps这个词的起源和DevOps运动的早期还是很清晰的：Patrick Debois是一名在IT行业的许多领域里很有经验的软件开发工程师兼顾问。他本人对于开发和运维之间的对立感到相当不爽。他试图在会议中引起大家对这个问题的兴趣，但是一开始并没有什么效果。
在2009年，O’Reilly Velocity大会上有个深得好评的演讲：“每日至少十次部署：开发和运维在Flickr的合作”。Patrick随即决定在比利时根特市组织一场名为DevOps之日的活动。这次，感兴趣的人变多了，这场大会获得了成功。“DevOps之日”这个名字引起了共鸣，而这场大会也延续了下来。在Twitter和大多数论坛里，DevOps之日被简称为DevOps。
DevOps运动的根源写在了敏捷软件开发原则里。在2001年，有些人想要改进一成不变的软件开发模式，并寻找新的工作方法，他们编写了敏捷宣言。下面是敏捷宣言里被奉为经典的摘录：
“个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。”
由此可见，DevOps可以说是与第一条原则密切相关的——“个体和互动高于流程和工具。”
显然这能够给工作带来好处——那为什么我们还要强调这么明显的事呢？如果你在大型企业里工作过，你就会知道事实上经常是反着来的。哪怕是看起来没什么障碍的小企业，里面的各个部门也很容易就筑起高墙。
DevOps，想要强调个体和互动是非常重要的，并且这个技术很可能有助于拆除企业里的部门墙。看起来可能有点儿反直觉，因为第一条原则更青睐于交互而不是工具。但是我认为使用任何工具都能起到多种效果。只要工具用得适当，就能帮我们得到所有想要在敏捷中获得的东西。
举个非常简单的例子，一个选择系统过去经常有缺陷。通常，开发团队和测试团队会用不同的系统来处理任务和缺陷。这样的事不仅在团队中导致了不必要的摩擦，并且把本应一起工作的双方隔离开了。而运维团队很可能又会用第三种系统来处理服务器的部署请求。
另一方面，有DevOps观念的工程师，会立即意识到所有的三个系统都是相似的工作流程。三个团队里的每个人应该都有使用一个相同系统的可能性，也许只需要为不同的角色展示不同的界面就可以了。因为三个系统变成了一个，所以会带来减少维护成本的长期利益。
DevOps的另一个核心目标是自动化和持续交付。简单来说，自动化一切可重复的乏味的工作，把更多时间留给人与人之间的交流，这才能产生真实的价值。
多快才算快？
DevOps化的转变必须要快。在高层次上，我们需要考虑抢占市场；在低层次上，我们需要盯紧任务。这也是持续交付运动的思路。
就像敏捷的很多东西一样，DevOps和持续交付虽然有许多概念名称不同，但是它们都有着相同的含义。它们只不过是一枚硬币的正反面而已，在概念上并没有什么争议。
DevOps工程师致力于让公司的流程更快、更有效，并且更可靠。只要有可能，就取代那些容易出错的重复性人力劳动。
尽管如此，在DevOps实践过程中很容易忘记最终目标。要是干得太慢，对任何人来说都没什么用。相反，我们必须把交付增加的商业价值牢记在心。
例如，增进企业内部各角色的交流就有很明显的价值。你的产品负责人可能想了解开发的进度并渴望能够先睹为快。这样的话，在测试环境上做到快速并有效地增量交付，将会非常有帮助。像产品负责人这样的利益相关者，当然还有质量保证团队，都能够在测试环境上跟上开发的节奏。
另一种观点是这样的：如果你曾经感觉到自己因为不必要的等待而注意力不集中，那么你的流程或工具有问题。如果你在程序编译时看机器人打气球的视频，那么你的编译时间太长了！
在团队等待部署这件事上也一样。当然了，整个团队白白呆着比一个人开销大多了。
机器人打气球的视频很有意思，不过开发软件也很让人兴奋！我们应该通过消除不必要的开销来关注创造潜能。

敏捷之轮
敏捷开发中有几个不同的周期，从投资级的周期，到Scrum和看板周期，再到持续集成周期。根据你使用的敏捷框架的不同，工作的侧重点也都有些许不同。看板所强调的24小时周期在运营团队里比较流行。而采用Scrum敏捷流程的开发团队，Scrum周期通常是2到4周。在大规模敏捷框架（Scaled Agile Framework）中，长周期也非常普遍，称为项目增量（Program Increments），可以持续数个Scrum Sprint周期。

DevOps要能够支持这些周期更好地运转。在DevOps的思想下这再正常不过了：在敏捷的企业中跨部门协作。
DevOps在短周期中能带来明显的实质效益，而这些效益会让长周期变得更有效率。俗话说不积跬步，无以至千里；不积小流，无以成江海。
下面是一些敏捷周期可以从DevOps获益的例子：
DevOps工程师维护的部署系统，让Scrum周期最后的交付更快、更有效。而交付每2到4周就会周期性地发生。
在经常手动部署的企业里，部署一次可能需要好几天。像这样在部署上没有效率的企业可以从DevOps观念中获益良多。
看板的周期是24个小时，所以很显然如果我们想要在看板方法上取得成功，部署的周期需要快得多。
一旦代码提交到代码库，取决于变更集的大小，一个设计良好的持续交付流水线大约只需要几分钟就可以把提交的代码部署到生产环境。
敏捷不只是形式
由于在量子物理上的成就，Richard Feynman在1965年获得了诺贝尔奖。他注意到科学家中的一个普遍现象，那就是他们覆盖了科学的全部边界，可是就偏偏漏掉了一些关键性因素。他把这种现象称为“草包族科学（cargo cult science）”。这来源于美拉尼西亚南部海岛上的草包族（cargo cult）。草包族这个说法是在第二次世界大战时，因岛上的土著居民观察到飞机给他们送货而产生的——战争结束之后，货物就不再送来了。土著们便开始模仿以前观察到的美军的行为，比如修建模拟机场，幻想飞机能因此再次回来。

如果我们只是早上站个会，喝点咖啡，聊聊天气，这并不是敏捷或者面向DevOps的方式。如果我们的Puppet只有运维团队才知道怎么用，这也不是DevOps流水线。
我们是否正在做正确的事？是否还在正确的路上？时刻关注我们的目标并经常问自己，是件非常重要的事情。这是敏捷思考的中心。然而，在实践中显然非常困难。很容易以草包族的方式而告终。
每当构建部署流水线的时候，举个例子，留神我们为什么要在第一时间构建它们。最终目标是让人们可以更快、更容易地和新系统交互。它帮助不同角色的人们更有效率地沟通，而不用改变太多。
另一方面，如果我们构建的流水线只是帮助了一个组的人们达成他们的目标，比方说运维组的人，那么对于达成最终目标来说，我们已经打了一场败仗。
虽然没有科学根据，但值得记住的是敏捷周期，比如Scrum的sprint周期，一般都会有办法来应对这种状况。Scrum里，这种办法被称为sprint回顾会议。在会上，团队一起讨论在上个sprint大家什么做得好以及什么可以做得更好。在这上面花点时间来保证你每天的工作都是在做正确的事情。
一个常见的问题是，spring回顾会议的结果并没有真正地被执行。很不幸，这可能是由于你和企业的其他部分沟通不畅的问题导致的。所以，这些问题在回顾会议上虐你千百遍，但是从来没有得到解决。
如果你意识到你的团队正处于这种情况，你将会从DevOps方法中获益，因为它强调企业内部的协作。
总结一下，尝试使用敏捷方法提供的机制。如果你正在使用Scrum，请使用sprint回顾会议机制来捕获潜在的改进空间。话虽如此，这些方法不是教条，找出适合你的方法。
DevOps和ITIL（信息技术基础架构库）
这一部分说明了在一个大整体中，DevOps和其他的工作方式怎么共存并互相适应。
DevOps在敏捷或者精益企业的许多框架里都能协作得很好。大规模敏捷框架，或者说SAFe®，都特意提到了DevOps。自从DevOps在敏捷环境中诞生以来，各种各样的敏捷实践和DevOps之间就几乎从来没有过分歧。然而，ITIL有些不同。
ITIL，信息技术基础架构库（Information Technology Infrastructure Library），是很多大型成熟企业采用的一种实践。
ITIL是个扮演了软件生命周期中许多角色的大型框架。DevOps和持续交付认为我们交付到生产环境的变更集应该小而频繁，乍一看，ITIL的观点似乎与之相反。然而这并不是事实。遗留系统通常是单块系统，在这些系统中，经常伴随着复杂变更，需要有一个像ITIL一样的流程来管理它们。
如果你正在一个大型企业里工作，那么很可能你正在和这样的大单块遗留系统一起工作。
还有，许多ITIL描述的实践可以直接转换成相对应的DevOps实践。ITIL规定了配置管理系统和配置管理数据库，这些类型的系统也是DevOps必不可少的一部分。
总结
本文概述了DevOps运动背景。探讨了DevOps的历史和它在开发和运维中的起源，以及敏捷运动。我们也了解了在大型企业中ITIL和DevOps如何共存，同时还讨论了怎样来避免草包族的反模式。你现在应该能够回答如何在大规模敏捷背景和不同的敏捷开发周期中使用DevOps。我们会逐渐地过渡到更倾向于技术和实践的主题，更多内容请见《DevOps实战》一书。

DevOps和持续交付相关推荐

DevOps与持续交付实践
Danilo Sato表示:DevOps是旨在打破开发团队与运维团队之间的壁垒的一次尝试,这两者对于成功的软件交付来说都是必不可少的.他的新作<实战DevOps:可靠的自动化软件交付>(D ...
《六周玩转云原生》- 云原生下的DevOps与持续交付
六周玩转云原生为了让开发者们在这个特殊的时期里可以学习到更多干货,京东智联云开发者特别策划了 <六周玩转云原生>系列课程,让我们的开发者可以迅速入门,持续充电. 时光倒流到本世纪初,&q ...
云原生下的DevOps与持续交付
课程概要 2009年,一场演讲在O'Reilly Velocity大会上一炮而红,演讲中有一句话深得人心:"由于开发和运维需要在Flickr(一个图片存储和视频托管网站)上合作,这导致开发者 ...
【转】持续交付和DevOps的前世今生
作者/分享人:乔梁,20年IT老兵,腾讯公司高级管理顾问,敏捷和精益开发专家,持续交付领域先行者.曾就职于百度,国内多个知名互联网公司的企业教练. 历年QCon技术大会的讲师和专题出品人. 这是一个新 ...
云原生（Cloud Native） = 微服务 + DevOps + 持续交付 + 容器化？
目录什么是云原生? 云原生之前云原生云原生简介微服务 DevOps 持续交付容器化云原生的发展历程云原生技术生态现状云原生基金会 -- CNCF 云原生技术社区云原生技术产业我们正 ...
持续交付流水线的敏捷利器：环境配置管理与应用部署自动化
作者介绍陈能技,DBAplus社群原创专家,新炬网络首席DevOps专家.14年开发测试与质量架构经验,擅长DevOps及APM.Docker.持续集成.持续交付在企业中的落地实施.著有<软件 ...
微服务怎么部署到服务器的_微服务的部署与发布：持续交付与持续部署微服务...
持续交付与持续部署微服务持续集成(Continuous Integration)与持续交付(Continuous Delivery ).持续部署(ContinuousDeployment)作为敏捷开 ...
构建高质量的持续交付体系
这是软件工程系列知识总结的第七篇文章,也是最后一篇. 前面的文章,聊了软件工程的基础理论.项目管理.需求分析.架构设计.软件测试以及线上服务的质量保障.其中在架构设计和线上服务的质量保障中,我也提到了 ...
大型金融企业DevOps持续交付实践
作者介绍符强,新炬网络DevOps专家,从事IT行业10余年,拥有丰富的开发.测试.运维工作经验.现致力于DevOps相关建设与实施推广的研究,具有多个大型电信.金融企业DevOps项目经验. De ...
快速指南：在DevOps中实现持续交付
[编者的话]时至今日,以几乎相同的步调实现开发与交付已经成为一种必需.本份快速指南将帮助大家弄了解持续交付概念中的那些"良方"与"毒药". [烧脑式Kubern ...

DevOps和持续交付

DevOps和持续交付相关推荐

最新文章

热门文章