一张图带你了解“持续交付”和“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 information 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方案给的太晚”
• “活儿太多”

测试：

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

运维：

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

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

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

从哪里找解决方案

（编辑：ASP站长网）