一张图带你了解“持续交付”和“DevOps”的前世今生

《一张图带你了解“持续交付”和“DevOps”的前世今生》要点：
本文介绍了一张图带你了解“持续交付”和“DevOps”的前世今生，希望对您有用。如果有疑问，可以联系我们。

这是一个新概念风起云勇的时代. 就让我们从云端抓它几个名词下来,一起玩耍吧!!! “敏捷软件开发”,“增长黑客”,“持续集成”,“DevOps”,“精益创业”,“持续交付”,“大数据”… …

OK,就这四个啦：

“敏捷软件开发”,“持续集成”,“DevOps”,“持续交付”,

先让我们在Wikipedia上验明正身.

在Wikipedia上的定义

敏捷软件开发

Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.

持续集成

Continuous Integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day

持续交付

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles,ensuring that the software can be reliably released at any time.

DevOps

DevOps is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and @R_505_4045@ion technology (IT) professionals while automating the process of software delivery and infrastructure changes.

我的解读

1. 敏捷软件开发方法

从来就没有一种方法,叫做“敏捷软件开发方法”.因为,IT行业中的“敏捷(Agile)”一词,从2001年它的诞生之日起,就是个软件开发方法集合,当时这个集合中的方法,都遵从敏捷宣言和相同的工作原则(十二原则),它的缔造者是十七位软件工程师(请查敏捷,雪鸟会议).目前,在这面大旗下,又增加了很多种方法,当然也有很多方法走出了人们的视线.

在国内比较活跃的几种方法：极限编程XP(2009年以前),Scrum及其进化品(2006年至今),精益软件开发方法(2009年至今),看板方法(2012年至今).当然,现在好象也不再特意强调“敏捷宣言”和“十二原则”了,只在培训课堂上还能听到.

2. 持续集成

早在1999年KentBack的《解析极限编程》一书中,对“持续集成”这一概念就有提及,它是极限编程XP方法中的十二最佳实践之一.在2004年,Martin Fowler发表的一篇博文上,给“持续集成”下了一个定义,并一直沿用至今.即：“持续集成是一个软件开发实践,是指团队成员频繁地集成他们的工作成果,通常每天每个人至少集成一次,这样在团队内每天都会有多次代码集成,每次集成都有通过自动化的构建(包括测试)尽可能快地发现集成问题.” 这个概念已被软件研发团队广泛接受,但是其中提到做法,并未能全部落实,太困难了. 这是正常的,来自极限编程方法的实践,都是有挑战的,否则就不叫“极限”二字了.

3. DevOps

在2008年的一次敏捷大会上,运维相关人员就“敏捷基础设施(Agile Infrastructure)”展开讨论,并在2009年以后逐步发展成为一场大规模“运动”,它是期望改变开发团队和运维团队之间协作关系的一场运动.强调开发团队与运维团队的沟通与协作,同时将软件的交付与基础设施变更过程都能够自动化.近年基础设施及工具链的发展,也让DevOps多了一些发力点.

4. 持续交付

Jez Humble和David Farley在2010年《持续交付》一书中正式提出这个概念,它在书中被定义为：一系列的原则与实践的集合；通过这个集合,团队能够在低成本、短时间及低风险的状态下以增量方式将软件变更交到用户手上.Jez认为,持续交付有三个支柱,它们分别是持续集成、自动化测试和部署流水线(Deployment Pipeline).

它们的关系

1. 空间与时间维度

根据以上的信息,我认为它们在空间和时间维度的关系是这样的：

上面这个图是从实践或环境的角度来看它们之间的关系.那么,如果我们换一个角度呢?

2. 人或组织维度

我的微信签名是“别提概念,只解决问题!”.所以我更愿意从解决问题的角度看这些概念.一谈到问题,就有一个经典的话浮现在我脑海里：“所有的问题,都是人的问题”.所以,这个角度看到的才是本质.那么,它们的关系是什么呢?

持续集成,有助于打破开发人员和测试人员之间的“墙”.

敏捷开发,有助于打破研发团队(开发+测试)与业务(产品)人员之间的“墙”.

DevOps,有助于打破开发团队与运维团队之间的“墙”.

持续交付,则是希望从端到端的角度,考虑如何解决问题.

为什么从“人”开始

在我多年的持续交付践行及咨询工作中,总结的经验是：如果希望在最短的时间和成本内,取得最大的收获,那么在一开始,与“人”相比,技术实践并不需要太在意,即：最好还是先从“人”的角度看问题.真正去解决问题时,上面说的种种概念并不是那么重要.它们都是你用来解决问题的工具,而且其中的每一个工具(概念)都包含了很多个小工具(原则和实践).而且,在解决问题时,你也不必整套选择这些工具.

从哪里找问题

从参与者的问题陈述中找问题.比如：

老板：

• “项目经常延期” “做东西太慢”

产品：

• “老板的想法总变”
• “事情太多,忙成狗”
• “开发说这个实现不了”

开发：

• “需求总变”
• “UI方案给的太晚”
• “活儿太多”

测试：

• “需求变了没提前通知”
• “测试时间总被压缩,还要背锅”
• “重复测试太多遍”

运维：

• “每天这么多版本上线,活干不完,出事儿第一个背锅.”

每句话的背后都有很多含义.开挖吧～～

提问题的人是问题的创造者,也是接盘侠～

从哪里找解决方案

在《持续交付》一书的第十五章,提到一个“持续交付成熟度评估模型”.在这个模型中,包含如下六个维度：

• 构建管理和持续集成
• 环境与部署
• 发布管理和和符合性
• 测试
• 数据管理
• 配置管理

通过实际工作的验证,我发现,这里面缺失了一些东西.所以,增加了一些维度,并重组了一下,如下图所示：

我也没有称其为成熟度模型,而是“持续交付七巧板”.

是的,中国的传统玩具“七巧板”,这个儿时的玩具可以拼出各种各样的图形.也就是说,每个团队、企业都有不同的环境上下文(人也是环境的一部分),解决方案也不必一样,关键是你想解决什么(想拼成什么图形).

找正确的问题去解决

上面的诸多概念并不是你的问题或目标,而只是你的工具(手段).千万不要把手段当成你的目标来实现.很多人问：

• 怎么做持续交付?
• 怎么做持续集成?
• 怎么做敏捷?
• 怎么做DevOps?

我猜测你是想问：是否有捷径做XXX.当然有,多种途径里,一定有相对来说的捷径,但不一定是你期望的那种“捷径”.

• 我们做的是敏捷吗?
• 我们这么做持续交付,对吗?

我猜测你是想问：(某个人或部门)这么搞,是不是靠谱啊?

• 你这不是敏捷?
• 你这不是DevOps?
• 你这不是持续交付?
• 你这不是持续集成?

我想说：无所谓,因为我的在微信上的签名是：别提概念,只解决问题.我们还是先讨论清楚问题吧～

再炒一炒冷饭

2011年,我在InfoQ上发表了一篇案例文章《DevOps,不是一个传说!》,其中有两个评论比较有意思：

1. 怎么感觉就是一个从瀑布模型到Scrum/CI的变化?
正如我们上面第二张图所示,这个项目的前期工作,的确主要是在敏捷开发的范畴,但文中还是提到一小部分Ops方面的东西,可能评论者没有注意到吧.或者没有看到他想找的内容.

2. 标题党啊
好吧,我承认在那个很少有人提及“DevOps”的年代,我就做标题党吧.

这个案例就混合了上面所有的概念,但在项目里,谁还在意概念呢,达成结果最重要.

一、了解环境背景

当任何人想要对组织进行改变时(无论改变的大小,你叫它改进、转型或者变革都可以),一定先要了解组织的历史,感受组织的文化,因为组织的历史决定了问题的来源,定义了问题的范围.

几年前的百度,工程管理相对固化,敏捷还在“小步快跑,越变越美”的倡导期(从瀑布到迭代,强调项目管理中的迭代概念).一个从Google跳槽加盟百度的技术经理在自己的部门里倡导“主干开发(Single Branch mode)”,但由于原有的基因特别强大,进展艰难. 而这个项目是在最有百度特质的大搜索团队,试验田是一个10人左右的工程架构团队.

团队间接管理者

• 项目交付不太可控：
  • 我们一直在做计划,但计划性非常差.
  • 经常有各种各样的情况发生,总会让项目改期.

团队直接管理者

• 我非常希望能够快速交付,但我们对这类架构变动类的项目不知道怎么能做到.
• 这个项目中,有一部份需求必须在XXX时间点完成.

团队Lead

• 估算不准确、临时插入事情多、项目计划很难做(这里省略一千字).
• 我不知道怎么改进,因为我周围的团队也是这样,而且一直这样工作.

开发人员

• 领导说试一下,就试一下吧.

测试人员

• 工作经常被打断.
• 提测质量不高,经常浪费精力.
• 出了Bug,影响太大.
• (这里省略一千字).

二、找到正确的问题来解决(目标)

三个月内：

(１)该项目交付时间可预期.

(２)建立新的软件开发协作方式.

(３)建立必要的基础设施,以支持后续的持续发布模式.

三个月后：

(１)需求的周期时间缩短,可以短周期上线.

(２)生产环境的质量不降低.

(３)测试人力总投入降低.

在少于30人的团队(61个人也可以～哈哈～那62个人呢～～～)

1. 通常行为的改变,需要一个半月的时间；
2. 带来强烈可感知的收益需要三个月的时间.

三、承诺是必须的

上面的问题(目标)找到了,也要一并承诺.

要想让团队和你走,你必须站在前面.

四、培训及过程指导

需要解决团队提出的任何疑问,如果当时不知道如何解决,也要承认.

启蒙培训(1小时)

对于这种能够直接认识团队每个人的小团队,一开始就别花费太长时间讲大道理,以解决具体问题的方式来启蒙.

重新定义工作流程

• 新的项目工作流程
• 新的迭代工作流程
• 新的需求工作流程

• 新的代码工作流程

解决新流程中的障碍

• 团队沟通和协作的方式.
• 编译环境的准备.
• 编译时间的缩短.
• 自动化测试策略的制定,比如：我们放弃了原教旨主义的单元测试.

• 自动化测试运行的环境的准备.
• 自动化测试编写时机与自动化的利用.
• 自动化测试用例代码管理.

我和运维人员的对话(真实的场景再现)

我：我们团队想每两周就部署一次服务 运维：不行 我：为啥? 运维：线上需要稳定 我：每两周部署一次,就不稳定了吗? 运维：原来的质量太差,每次上线总是出问题 我：现在质量很好 运维：怎么可能? 我：我们改变了工作方法,质量优先,你可以参加我们的站会.你有什么要求,我们都可以满足； 运维：那也不行 我：为啥 运维：我没有那么多时间.一次部署要涉及370多台机器.原来三个月上线一次,每次前前后后要折腾两天.现在每两周上线一次,我还哪里有时间去干其它业务线的活啊?

怎么解决?

改变部署方式,让他的工作生活美好起来吧～～～～～

• 部署流水线的建立,要求一键部署
  • 运维人员负责编写部署脚本,并做版本管理.
  • 开发人员在开发自测时使用同样的脚本.
  • 测试人员在测试环境上使用同样的脚本.
  • 运维人员在生产环境上也使用同样的脚本.

作者：乔梁
20年IT老兵,腾讯公司高级管理顾问,敏捷和精益开发专家,持续交付领域先行者.曾就职于百度,国内多个知名互联网公司的企业教练. 历年QCon技术大会的讲师和专题出品人,相关内容收集在持续交付中文站 http://www.continuousdelivery.com