这是一个新概念风起云勇的时代。
就让我们从云端抓它几个名词下来，一起玩耍吧！！！ “敏捷软件开发”，“增长黑客”，“持续集成”，“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方案给的太晚”
“活儿太多”
测试：
“需求变了没提前通知”
“测试时间总被压缩，还要背锅”
“重复测试太多遍”
运维：
“每天这么多版本上线，活干不完，出事儿第一个背锅。”
每句话的背后都有很多含义。开挖吧～～
提问题的人是问题的创造者，也是接盘侠～
从哪里找解决方案
在《持续交付》一书的第十五章，提到一个“持续交付成熟度评估模型”。在这个模型中，包含如下六个维度：
构建管理和持续集成
环境与部署
发布管理和和符合性
测试
数据管理
配置管理
通过实际工作的验证，我发现，这里面缺失了一些东西。所以，增加了一些维度，并重组了一下，如下图所示：
我也没有称其为成熟度模型，而是“持续交付七巧板”。
是的，中国的传统玩具“七巧板”，这个儿时的玩具可以拼出各种各样的图形。也就是说，每个团队、企业都有不同的环境上下文（人也是环境的一部分），解决方案也不必一样，关键是你想解决什么（想拼成什么图形）。
找正确的问题去解决
上面的诸多概念并不是你的问题或目标，而只是你的工具（手段）。千万不要把手段当成你的目标来实现。很多人问：
怎么做持续交付？
怎么做持续集成？
怎么做敏捷？
怎么做DevOps？
我猜测你是想问：是否有捷径做XXX。当然有，多种途径里，一定有相对来说的捷径，但不一定是你期望的那种“捷径”。
我们做的是敏捷吗？
我们这么做持续交付，对吗？
我猜测你是想问：（某个人或部门）这么搞，是不是靠谱啊？
你这不是敏捷？
你这不是DevOps？
你这不是持续交付？
你这不是持续集成？
我想说：无所谓，因为我的在微信上的签名是：别提概念，只解决问题。我们还是先讨论清楚问题吧～
再炒一炒冷饭
2011年，我在InfoQ上发表了一篇案例文章《DevOps，不是一个传说！》，其中有两个评论比较有意思：
1. 怎么感觉就是一个从瀑布模型到Scrum/CI的变化？
正如我们上面第二张图所示，这个项目的前期工作，的确主要是在敏捷开发的范畴，但文中还是提到一小部分Ops方面的东西，可能评论者没有注意到吧。或者没有看到他想找的内容。
2. 标题党啊
好吧，我承认在那个很少有人提及“DevOps”的年代，我就做标题党吧。
这个案例就混合了上面所有的概念，但在项目里，谁还在意概念呢，达成结果最重要。
一、了解环境背景
当任何人想要对组织进行改变时（无论改变的大小，你叫它改进、转型或者变革都可以），一定先要了解组织的历史，感受组织的文化，因为组织的历史决定了问题的来源，定义了问题的范围。
几年前的百度，工程管理相对固化，敏捷还在“小步快跑，越变越美”的倡导期（从瀑布到迭代，强调项目管理中的迭代概念）。一个从Google跳槽加盟百度的技术经理在自己的部门里倡导“主干开发（Single
Branch mode）”，但由于原有的基因特别强大，进展艰难。 而这个项目是在最有百度特质的大搜索团队，试验田是一个10人左右的工程架构团队。
团队间接管理者
项目交付不太可控：
我们一直在做计划，但计划性非常差。
经常有各种各样的情况发生，总会让项目改期。
团队直接管理者
我非常希望能够快速交付，但我们对这类架构变动类的项目不知道怎么能做到。
这个项目中，有一部份需求必须在XXX时间点完成。
团队Lead
估算不准确、临时插入事情多、项目计划很难做（这里省略一千字）。
我不知道怎么改进，因为我周围的团队也是这样，而且一直这样工作。
开发人员
领导说试一下，就试一下吧。
测试人员
工作经常被打断。
提测质量不高，经常浪费精力。
出了Bug，影响太大。
（这里省略一千字）。
二、找到正确的问题来解决（目标）
三个月内：
（１）该项目交付时间可预期。
（２）建立新的软件开发协作方式。
（３）建立必要的基础设施，以支持后续的持续发布模式。
三个月后：
（１）需求的周期时间缩短，可以短周期上线。
（２）生产环境的质量不降低。
（３）测试人力总投入降低。
在少于30人的团队（61个人也可以～哈哈～那62个人呢～～～）
通常行为的改变，需要一个半月的时间；
带来强烈可感知的收益需要三个月的时间。
三、承诺是必须的
上面的问题（目标）找到了，也要一并承诺。
要想让团队和你走，你必须站在前面。
四、培训及过程指导
需要解决团队提出的任何疑问，如果当时不知道如何解决，也要承认。
启蒙培训（1小时）
对于这种能够直接认识团队每个人的小团队，一开始就别花费太长时间讲大道理，以解决具体问题的方式来启蒙。
重新定义工作流程
新的项目工作流程
新的迭代工作流程
新的需求工作流程
新的代码工作流程
解决新流程中的障碍
团队沟通和协作的方式。
编译环境的准备。
编译时间的缩短。
自动化测试策略的制定，比如：我们放弃了原教旨主义的单元测试。
自动化测试运行的环境的准备。
自动化测试编写时机与自动化的利用。
自动化测试用例代码管理。
我和运维人员的对话（真实的场景再现）
我：我们团队想每两周就部署一次服务
运维：不行
我：为啥？
运维：线上需要稳定
我：每两周部署一次，就不稳定了吗？
运维：原来的质量太差，每次上线总是出问题
我：现在质量很好
运维：怎么可能？
我：我们改变了工作方法，质量优先，你可以参加我们的站会。你有什么要求，我们都可以满足
运维：那也不行
我：为啥
运维：我没有那么多时间。一次部署要涉及370多台机器。原来三个月上线一次，每次前前后后要折腾两天。现在每两周上线一次，我还哪里有时间去干其它业务线的活啊？
怎么解决？
改变部署方式，让他的工作生活美好起来吧～～～～～
部署流水线的建立，要求一键部署
运维人员负责编写部署脚本，并做版本管理。
开发人员在开发自测时使用同样的脚本。
测试人员在测试环境上使用同样的脚本。
运维人员在生产环境上也使用同样的脚本。
如果想了解更多，我的“持续交付”微信公众号上对这个案例进行连载分析。感兴趣就来我的Chat交流吧。
善意的提醒
强烈建议大家仔细研读《持续交付》，尽管这是一个大部头著作，而没有代码，少量插图，也没有什么工具使用说明。
我正在写一本关于持续交付案例解读相关的书，希望能帮助大家。书中很多内容是我在实际工作里如何运用书中的理论和原则，做出我认为适当的选择（比如上例中的不做单元测试），帮助团队解决实际问题。 |
