「Book」- Continuous Delivery 2.0

更新日期:2019年07月10日

“重新定义”持续交付,增补「组织管理」和「架构」两个维度,附带真实案例,解读持续交付的「原则」和「实践」,论述了一些取舍的原则。

内容分为三部分:

	从作者的工作、实践经验出发,对原由的持续交付模型进行了修正,重新定义「持续交付为实现组织战略目标的能力」,引入了持续交付的「能力模型」。
	打造持续交付要遵循的一些原则,包括「基础原则」、「组织原则」、「架构原则」
	案例解读,阐述如何根据组织的当前状况,应用某些原则对最佳实践进行取舍,并快速达到组织能力目标。

读者对象:

	* 大型互联网公司的技术VP(技术副总裁)、技术负责人
	* 中小型互联网公司的CTO、技术VP、研发/运维/测试负责人,主管/骨干,
	* 组织变革者
	* 那些身处IT业务一线的管理者,或即将成为一线管理者的骨干技术人员
	* 那些从事软件产品项目管理和软件过程改进的人们
	* 新公司的创立者或高速发展的成长期公司技术高管
	* !!!不是为那些已经成熟的大型软件企业的高层管理者服务的

作者:

	乔梁,腾讯的敏捷咨询顾问,《持续交付》中文版译者,腾讯高级管理顾问,“轻敏捷”方法创始人,持续交付先行者,映客、卷皮、墨迹天气等多家移动互联网公司高级管理顾问,也为魅族、上汽、平安等不同类型的公司提供组织管理咨询服务。

分享的目的:

	对「持续交付」有一个基本的认识;
	了解一些新颖的思想,新颖的问题处理方式,学习别人的实践经验;
	推荐《持续交付 2.0》这本书;

序一(Jez Humble,DORA联合创始人兼CEO)

《持续交付》的作者与乔梁合作,共同开发GoCD项目(第一个支持部署流水线的CI/CD工具),这其中的经验为《持续交付》提供了非常多的素材。过去的十年这些内容已经从「最前沿的想法」变成「业内公认的智慧」。

	每个卓越的公司都希望能够随时发布,无需工程师在晚上或者周末进行部署。(能力)
	能够进行快速、频繁、安全地发布软件,并实现小批量的交付,意味着可以快速获得对我们的想法进行反馈。(能力)
	可以构建一个原型,并使用真实用户进行测试''(A/B TEST)'',获得用户反馈,以避免开发对用户没有价值的功能。(能力)
	反过来,也意味着产品更好,客户满意,员工更快乐(???)。(工作方式)

这些能力对需要「这种工作方式」(客户满意……)的每个组织来说,都是非常关键的。(要想实现这种工作方式,具备这些能力是非常重要的)

然而,获得这种能力并不是非常容易的事情。需要组织架构的不断演进,使其支持尽快且有效的测试、快速的部署,还要培训快速测试的文化。「文化因素」对于「成功实施持续交付」和「通过持续交付实现产品管理实践」至关重要。

序二(曾宇,腾讯的副总裁(VP))

我们处在移动互联网时代的下半场。这意味着,对于主流人群来说,头部的基本需求或许已经被满足或者说“饱和”,而未来的方向或许是现有模式的颠覆,或许是长尾个性化需求的充分满足,又或许是小众人群的挖掘。无如何,我相信未来创新的成本和创新失败的可能性有很大的机会持续走高。

在这种大背景下,如何通过极致的产品研发运营效率,快速发现新的机会,降低创新成本就变得尤为重要。

乔梁:“质量与速度根本不存在平衡,只有在产品能够承受的一定质量水准基础上,追求交付的速度才有意义”。虽然不同的产品阶段对产品质量要求有不同的定义,但在同一产品阶段中,质量要求却几乎是稳定的。本书中所讨论的内容全部围绕“如何在满足质量要求的前提下快速交付产品价值”这一问题展开。

	为了快速发现新的机会,必须加快产品迭代速度,
	而迭代速度的加快也会让一些固定成本(例如,为达到发布质量所需的测试成本,以及产品发布流程所需承担的成本)在每个迭代中所占的比例突显。
	这种事务性成本在很大程度上阻碍了产品的迭代速度。
	书中对持续交付“价值探索环”与“快速验证环”中每个步骤的详细拆解,一方面:''会让你开阔对业务问题的思考维度与角度'',另一方面也能让你发现:**在日常工作中就有很多细节可以优化,从而降低迭代中的固定成本,有效提升产品创新效率。**
	与此同时,也会在潜移默化中提高团队的整体战斗力。

自序

《解析极限编程》,介绍的软件开发方法与现实中使用的工作方法截然不同。书中的很多实践看上去都不现实,如测试驱动开发、持续集成、结对编程、用户故事等。

作者带着“怀疑”的态度,在实际工作中引入了其中一些方法,但执行上还是打了一些折扣。例如,我没有做测试驱动开发,而只是增加一些单元测试;没有做结对编程,而是要求代码评审(code review),没有做持续集成,而是每日构建段,虽然能感受到一些收益,但并没有那么显著。

直到2005年,作者的一个朋友向我展示了他们如何使用这种开发方式交付真实的软件项目,和真实的编写代码的过程。

	每一次修改代码,都编写并执行一系列的自动化测试用例;
	每次提交都会进行持续集成。

这是一种从未有过的编码体验,开发工程师很少需要启动程序,通过单步调试来找出代码中的问题。这使我真正相信,的确存在按照这种敏捷方式工作的团队,而且离我并不遥远。

2007年,我认为包括极限编程在内的众多敏捷开发实践是快速高质量软件交付的法宝;

2010年之后,我发现实践本身虽然非常重要,但更重要的是支撑实践的组织管理方法、工作思路与理念。于是,我的口头禅成了“别提敏捷,只解决问题!”。

2012年后,更多的软件开发方法与敏捷流派在国内开始盛行,但其背后的核心理念与主要工作原则并没有根本性的变化。

	无论什么样的方法,都应该以“解决问题为出发点,
	而“解决问题”的一个重要前提是“能够正确定义问题,并达成共识”,
	但是从以往的经历上看,对事物的正确理解,并不能确保正确的思想和理念在现实中**落地**,也不能确保对企业有大的和直接的帮助。
	对方法应用者而言,其目标是通过对思想理念的认知,能够尽早解决自己(或者客户)所面临的棘手问题''(解决问题)''。正如企业经营管理一样,软件工程发展的历程也是各种方法论不断出现与发展的过程。从20世纪60年代“软件工程”这一术语的诞生,到20世纪70年代提出瀑布软件开发模型,以及1985年提出的迭代增量开发和1986 Barry Boehm Spiral Model of Software Development and Enhancement”一文中提出的喷泉模型,20世纪90年代的软件能力成熟度模型集成(Capability Maturity Model Integration,CMMI)的产生和多种轻量级软件开发方法,21世纪初敏捷宣言的正式发表,再到精益软件开发方法、看板方法,以及持续交付和 DevOpsi运动。所有这一切变化,既反映出该领域的快速变化,也反映出「没有哪一种理论或方法能够完全解决这个领域面临的所有问题」。

本书希望能够让读者在了解“持续交付”全貌的基础上,当遇到与IT组织效能相关的问题时,能够以适当的思考方式和背景知识来应对,让你在今后的工作中少走一些弯路,至少遇到相似问题时,可以有所参考。

前言

“持续交付”是一个非常有吸引力的名字,总会让人浮想联翩,业务人员似乎看到了一丝希望“所有的需求,上午提出来,下午就能拿到手”。

然而,太多的企业低估了自己所面临的困难。

	这些困难一部分是显性的,如没有自动化测试,也做不到自动化部署,主千开发更是不可想象''(GIT分支模型)'';
	还有一部分困难是隐性的,例如,职能部门之间的“墙”存在已久。业务人员嫌开发团队的软件交付速度慢,开发团队嫌业务人员提出的需求不靠谱。这很可能归因于每个人的价值思考方式。

本书的目标是希望企业中所有角色转换「价值思考的角度」,改进软件服务端到端的商业价值交付方式,提升相关人员之间的协作效率,最终达到以安全可靠的方式快速验证想法,缩短实现真正商业价值的时间。也就是说,本书不仅关注“从需求列表到可运行的软件”这一过程,还提出“价值探索一快速验证”双闭环,如图所示,这也是本书的书名“持续交付2.0”的由来。

事实证明,没有放之四海皆准的企业管理解决方案,能够完美解决每个企业遇到的问题。但是,管理者只有从整体视角出发,抵住局部优化的诱惑,才能在资源有限的情况下,引领企业创造更大的价值。本书提供了一个整体框架,给出了这个框架中各节点所涉及的原则与相关的实践方法,同时介绍了它们的优势与约束。

如果你将“持续交付2.0双环模型”

	应用到整个企业范围,就是一种企业级的组织管理变革指引;
	如果你将它引入某一个团队,对这个团队来说,就是团队工作模式的改进套路。

既然“持续交付2.0”是一个管理框架,企业势必要根据自己的实际情况来进行定制。因此,书中列举了很多实际案例,告诉你,其他企业或团队如何应用这些实践方法,达到它们的目标。这些案例也说明,解决方案与实施路径很难在企业之间进行复制,企业必须应用书中的原则,结合自身的实际情况(产品形态及所处的商业竞争阶段、团队的规模与人员技能水平、软件系统架构,以及组织管理机制与文化等),逐步探索出自己的道路。

读者对象
本书主要服务于那些身处IT业务一线的管理者,或即将成为一线管理者的骨干技术人员,当然也包括那些从事软件产品项目管理和软件过程改进的人们。对新公司的创立者或高速发展的成长期公司技术高管也有参考作用。它并不是为那些已经成熟的大型软件企业的高层管理者服务的。当然,如果他们也认为本书有所帮助,那我也非常高兴。

对于产品经理、开发经理、测试经理和运维经理可以从本书中获得更全面的工作视角,发现自己领域之外更多的信息,以及如何与其他角色协作共赢。

对于过程改进者或者变革者,可以从本书中了解其他团队或公司的做法,希望能给你带来工作上的灵感。

对于新公司的创立者与高速成长公司的高管,希望可以从本书中找到一些管理方式与高效方法,使得公司在成立和发展之初,就能够以尽可能少的成本,支持你的事业持续高速发展。

内容简介

书中有很多案例,用于帮助读者理解“持续交付20”的双环模型,与其中各环节应用的不同实践。

全书共包括3部分内容。

	第一部分介绍了“持续交付2.0”的双环模型;
	第二部分主要讨论使用“持续交付2.0”框架中可能遇到的问题,以及改进过程中需要遵循的原则。
	第三部分主要是案例分享,目的是让读者体会在持续改善过程中,不同企业和团队的实施重点与解决方案的不同。书中具体内容如下所示。

第一部分,主要讲述“持续交付2.0”双环模型(即持续交付“8”字环)和“持续交付2.0”的4个工作原则,还会介绍两个闭环“价值探索”与“快速验证”的执行步骤与相关原则。

	第1章,讨论持续交付的发展必然性,并介绍“持续交付2.0双环模型”及其4个基本原则。
	第2章,讨论“价值探索环”(简称“探索环)的4个核心环节,以及每个环节的指导原则与实践方法。只有「业务方」能够以“精益”方式思考,持续交付才能更显威力,否则很可能退缩成为「持续交付1.0」的「单环模式」,即只有“快速验证环”
	第3章,简单阐述“快速验证环”(简称“证环”)中各环节的主要活动,并给出各环节的工作方法。

第二部分主要阐述“持续交付2.0”的实施七巧板中的:

	三大主要板块的工作原则与实践方法。这三大板块包括「组织机制」、「软件架构」、「基础设施」。
		其中「组织机制」是一个复杂课题,本书仅讨论持续交付所需的文化,以及建立文化的四步法。
		「组织架构」、「人才结构」、「激励机制」等内容将在本书的续篇中专题讨论。
		''「基础设施」''部分是产品研发过程中最基础的工作。这部分首先讨论持续交付部署流水线及其工具设计原则,然后分别介绍部署流水线的建立与优化必须关注的五大领域:「业务需求协作流程」、「分支与配置管理」、「构建与环境管理」、「自动化测试管理」,「部署发布与监控管理」。
	第4章,讨论持续交付能力的提升需要企业具有信任、安全和持续改善的组织文化,并介绍丰田公司和谷歌公司用过的改善组织文化四步法。
	''第5章'',讨论软件架构对实现持续交付快速验证能力的重要性、有利于持续交付的软件架构特征,以及软件架构改造的3种方式,即“拆迁”“绞杀”和“修缮”。
	''第6章'',讨论如何利用约束理论和精益思想,**发现流程中的瓶颈**,使各角色之间的业务需求协作更加顺畅,提升需求流动速度。
	''第7章'',讨论快速验证环所依赖的部署流水线的设计原则与工具链建设草案。
	''第8章'',讨论代码仓库的「分支方式」对持续交付的重大影响,以及不同分支方式下部署流水线的建设方案。最后介绍代码分支的数量对发布策略的影响。
	''第9章'',回顾持续集成的历史,并讲解如何判断团队是否在实践“持续集成”,还给出企业实施持续集成的五大步骤。
	''第10章'',讨论软件发布以前制订自动化测试策略需要考虑的因素,还介绍持续集成对自动化测试用例的编写与运行要求。最后,为了提高自动化测试的投资回报率,团队如何为遗留系统编写和增加自动化测试用例。''(测试部门)''
	''第11章'',讨论软件配置管理,它是持续交付快速验证环的基础。**对代码、配置、环境、数据做好配置管理,最终实现一键部署和一键测试**''(码云组织命名就是反例)'',让各角色在协作过程中能够全部实现自动化服务,并且互不影响,解放人的大脑和双手,做更有价值的事情,而让机器做它擅长的事—不断地重复。
	''第12章'',讨论降低生产部署与发布风险的技术与方法。
	''第13章'',讨论软件在运行时,数据收集与分析的重要性,以及衡量数据监测环节的衡量指标,包括正确性、完整性和及时性,此外还介绍测试扁平化趋势,以及生产环境上的质量巡检与演习。

第三部分主要是实战案例的分析。它们分别代表不同类型的公司、不同大小的团队以及不同的软件产品特点。深入案例现场,了解当时状况,分析问题,并提出解决思路。

	第14章,介绍一个百人工程师的互联网产品团队历经一年时间,如何打造快速运转的“持续交付2.0双环模型”,并且做到可持续运转。
	第15章,介绍在无法“测试右移”的情况下,一个大项目中的小团队如何改变团队协作模式,从“死亡行军”转变为“无缺陷交付”。
	第16章,介绍一个微服务化开发团队如何在项目运行的过程中,通过逐步对基础设施板块中各模块进行改造,提升交付质量与频率,并推动运维人员也做出改变,真正成为一个 DevOps“团队”

如何阅读本书取决于读者的目标是什么。你可以按照章节从头到尾读下来。这样,你可以了解我在工作中应用到的知识体系,最终了解为什么“持续交付2.0是一种组织能力”,如何衡量这种组织能力,以及如何在具体的工作场景中运用相关原则解决具体的问题。

当然,读者也可以根据自己的兴趣以及工作中遇到的问题,选取不同的章节。例如,后面3章的具体案例分析包括小团队的改进案例、大团队的变革案例,甚至超大公司所用

第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.5 “改善套路”进行持续改进 57

4.6 小结 58

第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 分级构建 142
9.3.2 多人同时提交的构建 142
9.3.3 云平台的威力 143

9.4 在团队中实施持续集成实践 145

9.4.1 快速建立团队的持续集成实践 146
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 改进后状态 244

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

附录A 软件工程的三次进化 310
附录B 排序法做相对估算 323


ToC

序一(Jez Humble,DORA联合创始人兼CEO)

序二(曾宇,腾讯的副总裁(VP))

自序

前言

内容简介

第1章 持续交付2.0 1

1.1 软件工程发展概述 1

1.2 持续交付2.0 7

1.3 小结 13

第2章 价值探索环 14

2.1 探索环的意义 14

2.2 探索环的4个关键环节 15

2.3 工作原则 24

2.4 共创与精炼的常用方法 27

2.5 实施注意事项 32

2.6 小结 35

第3章 快速验证环 36

3.1 验证环的目标 36

3.2 验证环的4个关键环节 37

3.3 工作原则 39

3.4 小结 44

第4章 持续交付2.0的组织文化 45

4.1 安全、信任与持续改善 45

4.2 文化塑造四步法 46

4.3 行动原则 50

4.4 度量原则 55

4.5 “改善套路”进行持续改进 57

4.6 小结 58

第5章 持续交付的软件系统架构 60

5.1 “大系统小做”原则 61

5.2 常见架构模式 62

5.3 架构改造实施模式 66

5.4 小结 70

第6章 业务需求协作管理 72

6.1 产品版本周期概述 73

6.2 需求拆分的利与弊 75

6.3 需求拆分方法 79

6.4 需求分析与管理工具集 85

6.5 团队协作管理工具 87

6.6 小结 91

第7章 部署流水线原则与工具设计 92

7.1 简单的部署流水线 92

7.2 部署流水线的设计与使用 95

7.3 部署流水线平台的构成 97

7.4 基础支撑服务的云化 100

7.5 企业制品库的管理 107

7.6 多种多样的部署流水线 108

7.7 为开发者构建自助式工具 111

7.8 小结 113

第8章 利于集成的分支策略 114

8.1 版本控制系统的使用目的 114

8.2 常见分支开发模式 118

8.3 分支模式的演化 126

8.4 分支策略的选择 128

8.5 小结 133

第9章 持续集成 134

9.1 起源与定义 134

9.2 六步提交法 136

9.3 速度与质量的权衡 141

9.4 在团队中实施持续集成实践 145

9.5 常见的实施问题 150

9.6 小结 152

第10章 自动化测试策略与方法 153

10.1 自动化测试的自身定位 153

10.2 突破传统自动化测试的困境 156

10.3 自动化测试的实施策略 163

10.4 用户验收自动化测试要点 168

10.5 其他质量检查方法 173

10.6 小结 175

第11章 软件配置管理 176

11.1 将一切纳入配置管理 176

11.2 软件包的版本管理 181

11.3 包依赖管理 185

11.4 环境基础设施管理 191

11.5 软件配置项的管理 199

11.6 不可变基础设施与云应用 203

11.7 数据的版本管理 208

11.8 需求与源代码的版本关联 209

11.9 小结 209

第12章 低风险发布 211

12.1 高频发布是一种趋势 211

12.2 降低发布风险的方法 215

12.3 高频发布支撑技术 219

12.4 影响发布频率的因素 227

12.5 小结 228

第13章 监测与决策 229

13.1 生产监测范围 230

13.2 数据监测体系 231

13.3 问题处理体系 235

13.4 生产环境测试 237

13.5 向东,还是向西 240

13.6 小结 241

第14章 大型互联网团队的FT化 242

14.1 简介 242

14.2 改进方法论 245

14.3 改进的历程 246

14.4 小结 260

第15章 小团队逆袭之旅 262

15.1 背景简介 262

15.2 改进方法论 265

15.3 第一阶段:研发准备期 266

15.4 第二阶段:软件交付期 270

15.5 小结 281

第16章 研发推动的DevOps 283

16.1 改进的关键点 285

16.2 第一阶段:敏捷101 287

16.3 第二阶段:DevOps转型 302

16.4 小结 308