敏思特咨询公司联合创始人，腾讯外聘高级管理顾问，DevOps领域***导师之一，持续交付双环理论创始人，指导过很多大型软件公司解决组织转型与研发管理方面的相关问题。国内最早致力于通过敏捷开发与精益理论提升软件价值交付效率的实践者之一，精研各种软件工程方法论，2010年翻译《持续交付》一书，并结合8年实践将工作心得整理成《持续交付2.0：业务引领的DevOps精要》。十多年来，受邀参加各种大型技术会议（如QCon、AgileChina、DevOpsDays、MSTC等）并发表演讲。
读者可访问本书配套网站www.continuousdelivery20.com，持续获得作者的**分享，并参与互动和交流。

本书“重新定义”了持续交付，增补了组织管理和架构两个维度，辅助以真实案例，对持续交付的诸多原则和实践加以解读，并对持续交付过程中的取舍原则加以论述。
本书分为3个部分：第一部分作者根据自己近十年的工作及咨询经历，通过不断总结、提炼和反思，对原有的持续交付进行修正，重新定义持续交付为实现组织战略目标的能力，并引入持续交付的能力模型；第二部分阐述组织打造持续交付能力模型所需遵循的原则，包括基础原则、组织原则和架构原则；第三部分通过对多个互联网公司案例的解读，阐述如何根据组织的当前状况应用相关原则对最佳实践进行取舍，并快速达到组织能力目标。
本书适合大型互联网公司的技术VP、技术负责人，中小型互联网公司的CTO、技术VP、研发/测试/运维负责人、主管及骨干，以及组织变革者阅读。

乔梁老师是软件工程领域的大师，同时作为腾讯的敏捷咨询顾问，也和我们合作多年，亲历了移动互联网发展的全过程。乔梁老师对产品研发运营体系的种种问题可谓洞若观火，对于效率的追求可谓孜孜不倦，而本书是乔梁老师在大量实战项目中总结出来的理论框架，可谓历经千锤百炼。本书也许没有太多高深抽象的概念，但每一项原则和方法的背后，都有足够多的正反例支持，和乔老师为人处事的风格一样，低调、务实、简单，值得每一位钻研和应用高效产品研发运营体系的读者阅读体会。我相信，在互联网行业，效率代表未来。
——曾宇，腾讯公司副总裁


作为敏捷和持续交付领域专家，乔梁曾于2010年前后在百度任职，负责百度敏捷研发效率提升，通过系统化指导，快速打造了多个标杆团队。经过多年在该领域的实践与沉淀，乔梁将其心得整理成本书。书中首次提出，持续交付是一种组织能力，是软件企业长期核心竞争力之一，需要得到企业各级领导者的关注。这是一本实用的持续交付系统化实践指南，书中给出了软件产品研发的基本工作原则，以及大量的实战案例，为DevOps实践者提供了实用参考。
——李莹，百度集团副总裁、百度集团首席信息官


乔梁是国内最早的持续交付实践和推动者之一，他技术功底扎实，视角独特，观点犀利。本书提出了创新的双环理论，结合众多国内企业的实践经验，大幅充实了持续交付知识体系。这是一本你应该常备的、问题导向的、能给你落地指导的工具书。
——路宁，快手高级技术总监

Jez Humble和Dave Farley在2010年出版的《持续交付》一书，极大地推动了相关理念与实践在世界范围内的传播和推广，为企业破除技术组织内部的鸿沟，从技术敏捷向业务敏捷的迈进打下了坚实的基础。在此后的几年里，日渐广泛的运用，也为持续交付在技术和工具上带来了日新月异的发展和创新。《持续交付》一书中文版的译者乔梁，作为处于革新一线的布道者目睹、参与了这整个过程，并且积累了新的真知灼见。在本书中，乔梁提炼的双环模型是在组织级推进业务敏捷的有效工具，而相关实操案例也为实践者提供了鲜活的参考。这本书是近年这个领域难得的佳作。
——张松，ThoughtWorks中国区总经理


时间越来越稀缺，拿出整块时间来看书，有时称得上是一件非常奢侈的事情。选书最重要的是看作者，靠谱的作者是书籍质量的保证。2011年，乔梁将《持续交付》中文版带给大家，该书至今依然是软件工程实践**参考书籍之一。乔梁本人在这8年里，亦不断拓展持续交付边界，这期间我们时有沟通，每有进展便欣喜相聚分享。玉汝于成，本书凝结前序译本智慧和8年实践真知，将成为软件工作者认知升级的必备书籍。
——李涛， 百度开源办公室主任

在各种敏捷研发和DevOps的大潮中，持续交付的魅力始终不减，乔梁老师在本书中系统阐述了持续交付双环模型，从工作原则到实践方法，并使用了大量案例做说明，是其多年企业咨询经验的总结，对持续交付感兴趣的读者不要错过此书。
——叶渡，阿里巴巴资深技术专家

目录
第 1章　持续交付2．0 1
1．1　软件工程发展概述 1
1．1．1　瀑布软件开发方法 1
1．1．2　敏捷软件开发方法 2
1．1．3　DevOps运动 3
1．1．4　持续交付1．0 4
1．2　持续交付2．0 7
1．2．1　精益思想 8
1．2．2　双环模型 9
1．2．3　4个核心原则 11
1．2．4　持续交付七巧板 12
1．3　小结 13
第 2章　价值探索环 14
2．1　探索环的意义 14
2．2　探索环的4个关键环节 15
2．2．1　提问 16
2．2．2　锚定 17
2．2．3　共创 19
2．2．4　精炼 22
2．3　工作原则 24
2．3．1　分解并快速试错 24
2．3．2　一次只验证一点 25
2．3．3　允许失败 26
2．4　共创与精炼的常用方法 27
2．4．1　装饰窗方法 27
2．4．2　最小可行特性法 29
2．4．3　特区法 30
2．4．4　定向探索法 30
2．4．5　稻草人法 31
2．4．6　最小可行产品法 32
2．5　实施注意事项 32
2．6　小结 35
第3章　快速验证环 36
3．1　验证环的目标 36
3．2　验证环的4个关键环节 37
3．2．1　构建 37
3．2．2　运行 38
3．2．3　监测 39
3．2．4　决策 39
3．3　工作原则 39
3．3．1　质量内建 39
3．3．2　消除等待 40
3．3．3　重复事务自动化 43
3．3．4　监测一切 43
3．4　小结 44
第4章　持续交付2．0的组织文化 45
4．1　安全、信任与持续改善 45
4．1．1　失败是安全的 45
4．1．2　相互信任 45
4．1．3　持续改善 46
4．2　文化塑造四步法 46
4．2．1　行为决定文化 46
4．2．2　谷歌的工程师质量文化 48
4．2．3　Etsy的持续试验文化 49
4．3　行动原则 50
4．3．1　价值导向 51
4．3．2　快速验证 51
4．3．3　持续学习 51
4．4　度量原则 55
4．4．1　度量指标的4类属性 56
4．4．2　度量的目标是改善 57
4．4．3　古德哈特定律 57
4．4．4　度量应有行动决策 58
4．5 “改善套路”进行持续改进 58
4．6　小结 59
第5章　持续交付的软件系统架构 60
5．1 “大系统小做”原则 61
5．1．1　持续交付架构要求 61
5．1．2　系统拆分原则 61
5．2　常见架构模式 62
5．2．1　微核架构 62
5．2．2　微服务架构 63
5．2．3　巨石应用 64
5．3　架构改造实施模式 66
5．3．1　拆迁者模式 67
5．3．2　绞杀者模式 68
5．3．3　修缮者模式 68
5．3．4　数据库的拆分方法 70
5．4　小结 70
第6章　业务需求协作管理 72
6．1　产品版本周期概述 73
6．1．1　准备期 73
6．1．2　交付期 74
6．2　需求拆分的利与弊 75
6．2．1　需求拆分的收益 76
6．2．2　需求拆分的成本 78
6．3　需求拆分方法 79
6．3．1　需求的来源 80
6．3．2　技术债也是需求 80
6．3．3　参与需求拆分的角色 81
6．3．4　不平等的INVEST原则 82
6．3．5　五大拆分技法 82
6．3．6　七大组成部分 84
6．4　需求分析与管理工具集 85
6．4．1　用户故事地图 85
6．4．2　用户故事树 86
6．4．3　依赖关系图 87
6．4．4　需求管理数字化平台 87
6．5　团队协作管理工具 87
6．5．1　团队共享日历 88
6．5．2　团队回顾 89
6．5．3　可视化故事墙 90
6．5．4　明确“完成”的定义 90
6．5．5　持续集成 91
6．5．6　故事验证 91
6．6　小结 91
第7章　部署流水线原则与工具设计 92
7．1　简单的部署流水线 92
7．1．1　简单的产品研发流程 92
7．1．2　初始部署流水线 93
7．1．3　流水线执行状态解析 95
7．2　部署流水线的设计与使用 95
7．2．1　流水线的设计原则 95
7．2．2　团队的协作纪律 97
7．3　部署流水线平台的构成 97
7．3．1　工具链总体架构 97
7．3．2　平台应当具备的基本
能力 99
7．3．3　工具链建设策略 100
7．4　基础支撑服务的云化 100
7．4．1　基础支撑服务的协作过程解析 101
7．4．2　编译构建管理服务 103
7．4．3　自动化测试管理服务 104
7．4．4　软件部署管理服务 105
7．4．5　基础环境管理服务 106
7．5　企业制品库的管理 107
7．5．1　制品库的分类 107
7．5．2　制品库的管理原则 108
7．6　多种多样的部署流水线 108
7．6．1　多组件的部署流水线 108
7．6．2　个人部署流水线 109
7．6．3　部署流水线的不断演进 110
7．7　为开发者构建自助式工具 111
7．8　小结 113
第8章　利于集成的分支策略 114
8．1　版本控制系统的使用目的 114
8．1．1　集中式版本控制系统 114
8．1．2　分布式版本控制系统 115
8．1．3　版本控制系统中的基本概念 117
8．2　常见分支开发模式 118
8．2．1　主干开发，主干发布 118
8．2．2　主干开发，分支发布 119
8．2．3　分支开发，主干发布 121
8．3　分支模式的演化 126
8．3．1　“三驾马车”分支模式 126
8．3．2　Gitflow分支模式 127
8．3．3　GitHubFlow分支模式 128
8．4　分支策略的选择 128
8．4．1　版本发布模式 128
8．4．2　分支策略与发布周期的关系 132
8．5　小结 133
第9章　持续集成 134
9．1　起源与定义 134
9．1．1　原始定义 135
9．1．2　一次集成过程 135
9．2　六步提交法 136
9．2．1　4个关键点 138
9．2．2　同步与异步模式 139
9．2．3　自查表 140
9．3　速度与质量的权衡 141
9．3．1　分级构建 141
9．3．2　多人同时提交的构建 142
9．3．3　云平台的威力 143
9．4　在团队中实施持续集成实践 145
9．4．1　快速建立团队的持续集成实践 145
9．4．2　分支策略与部署流水线 148
9．5　常见的实施问题 150
9．5．1　工程师的开发习惯 151
9．5．2　视而不见的扫描问题 151
9．5．3　自动化测试用例的缺乏 151
9．6　小结 152
第 10章　自动化测试策略与方法 153
10．1　自动化测试的自身定位 153
10．1．1　自动化测试的优势 154
10．1．2　自动化测试所需的 投入 155
10．2　突破传统自动化测试的困境 156
10．2．1　传统自动化测试的特点 157
10．2．2　自动化测试的分层 157
10．2．3　不同类型的测试金字塔 160
10．3　自动化测试的实施策略 163
10．3．1　增加自动化测试用例的着手点 163
10．3．2　提高自动化测试的执行次数 164
10．3．3　良好自动化测试的特征 165
10．3．4　共享自动化测试的维护职责 166
10．3．5　代码测试覆盖率 167
10．4　用户验收自动化测试要点 168
10．4．1　先搭建分层框架 168
10．4．2　测试用例数应保持低位 171
10．4．3　为自动化测试用例预留API 171
10．4．4　为调试做好准备 171
10．4．5　测试数据的准备 171
10．5　其他质量检查方法 173
10．5．1　差异批准测试方法 173
10．5．2　代码规范检查与代码动静态检测 174
10．5．3　AI在测试领域的应用 174
10．6　小结 175
第 11章　软件配置管理 176
11．1　将一切纳入软件配置管理 176
11．1．1　软件配置管理的目标 176
11．1．2　软件配置管理的范围 177
11．1．3　软件配置管理的原则 177
11．2　软件包的版本管理 181
11．2．1　包管理的反模式 181
11．2．2　集中式包管理服务 182
11．2．3　软件包的元信息 183
11．3　包依赖管理 185
11．3．1　显式声明依赖 185
11．3．2　自动管理依赖 187
11．3．3　减少复杂依赖 188
11．4　环境基础设施管理 191
11．4．1　环境准备的4种状态 191
11．4．2　领域专属语言的应用 197
11．4．3　环境基础设施即代码 198
11．5　软件配置项的管理 199
11．5．1　二进制与配置项的分离 199
11．5．2　配置信息的版本管理 200
11．5．3　配置项的存储组织方式 201
11．5．4　配置漂移与治理 202
11．6　不可变基础设施与云应用 203
11．6．1　实现不可变基础设施 203
11．6．2　云原生应用 206
11．6．3　优势与挑战 206
11．7　数据的版本管理 208
11．7．1　数据库结构变更 208
11．7．2　数据文件 208
11．8　需求与源代码的版本关联 209
11．9　小结 209
第 12章　低风险发布 211
12．1　高频发布是一种趋势 211
12．1．1　互联网企业的高频发布 212
12．1．2　收益与成本共存 214
12．2　降低发布风险的方法 215
12．2．1　蓝绿部署 215
12．2．2　滚动部署 216
12．2．3　金丝雀发布与灰度发布 217
12．2．4　暗部署 218
12．3　高频发布支撑技术 219
12．3．1　功能开关技术 220
12．3．2　数据迁移技术 222
12．3．3　抽象分支方法 225
12．3．4　升级替代回滚 226
12．4　影响发布频率的因素 227
12．5　小结 228
第 13章　监测与决策 229
13．1　生产监测范围 230
13．1．1　后台服务的监测 230
13．1．2　分发软件的监测 230
13．2　数据监测体系 231
13．2．1　收集与处理 231
13．2．2　数据的标准化 232
13．2．3　监测数据体系及其能力衡量 233
13．3　问题处理体系 235
13．3．1　告警海洋与智能化管理 235
13．3．2　问题处理是一个学习过程 236
13．4　生产环境测试 237
13．4．1　测试活动扁平化趋势 237
13．4．2　生产环境中的测试 239
13．4．3　混沌工程 239
13．5　向东，还是向西 240
13．6　小结 241
第 14章　大型互联网团队的FT化 242
14．1　简介 242
14．1．1　改进前状态 243
14．1．2　改进后状态 245
14．2　改进方法论 245
14．2．1　指导思想 245
14．2．2　改进步骤 245
14．3　改进的历程 246
14．3．1　架构解耦 246
14．3．2　组织解耦 248
14．3．3　研发流程再造 250
14．3．4　自动化一切 259
14．4　小结 260
第 15章　小团队逆袭之旅 262
15．1　背景简介 262
15．1．1　改进前的“死亡行军”之旅 264
15．1．2　改进后的无缺陷交付 264
15．2　改进方法论 265
15．2．1　指导思想 265
15．2．2　试点团队的选择 265
15．3　第 一阶段：研发准备期 266
15．3．1　功能简介与需求拆分 266
15．3．2　架构设计与需求依赖识别 267
15．3．3　工作量估算与排期 268
15．4　第二阶段：软件交付期 270
15．4．1　通过可视化看板改进工作流程 270
15．4．2　无缺陷交付 277
15．4．3　主干开发与持续集成 278
15．4．4　测试活动左移 279
15．4．5　代码评审 279
15．4．6　关注结果，更要关注
过程 280
15．5　小结 281
第 16章　研发推动的DevOps 283
16．1　改进的关键点 285
16．1．1　改进方法论 285
16．1．2　定义改进目标 285
16．2　第 一阶段：敏捷101 287
16．2．1　做个靠谱的计划 287
16．2．2　开发阶段启航 291
16．2．3　对过程质量的约束 294
16．2．4　阶段性改进点 301
16．3　第二阶段：DevOps转型 302
16．3．1　与运维人员的“冲突” 303
16．3．2　高频部署发布中的具体障碍 304
16．3．3　整体解决方案的设计 304
16．3．4　DevOps阶段的团队改变 308
16．4　小结 308
第 17章　研发组织效能提升的必经之路 310
17．1　知识工作者与熵增定律 310
17．1．1　每个工程师生产的都是非标品 310
17．1．2　软件工程的复杂性令研发效率降低 311
17．2　一致性是效能提升的必经之路 313
17．3　组织能力三要素 314
17．4　胜任力评估 315
17．4．1　组织胜任力评估模型 316
17．4．2　个人胜任力培养体系 318
17．5　组织健康度 319
17．6　小结 320
附录A　软件工程的三次进化 321
A．1　软件工程的诞生 322
A．1．1　软件危机 322
A．1．2　瀑布软件开发模型 322
A．2　二次进化：敏捷开发 324
A．2．1　前奏——螺旋模型 324
A．2．2　敏捷宣言的诞生 324
A．2．3　敏捷软件开发方法的演化 328
A．2．4　敏捷软件开发方法小结 329
A．2．5　TPS启发下的软件开发方法 330
A．3　三次进化：DevOps 331
A．3．1　DevOps运动的兴起 331
A．3．2　持续交付的诞生 332
A．4　小结 333
附录B　排序法做相对估算 334
B．1　排序法相对估算 334
B．2　相对排序法的操作过程 335
B．3　小结 338