持续交付和DevOps的前世今生

名词解读

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方案给的太晚”
• “活儿太多”

测试：

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

运维：

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

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

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

从哪里找解决方案

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

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

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

（作者：乔梁）