高质效交付：软件集成、测试与 发布精进之道

定　　价：100 元

• 作者：董越 等
• 出版时间：2024/10/1
• ISBN：9787121489198
• 出 版 社：电子工业出版社

• 中图法分类：TP311.52 
• 页码：344
• 版次：01
• 开本：16开

内容简介

这是一本介绍软件交付过程的“科普小册子”。软件交付过程是指修改了一行源代码之后的一系列工作，直到包含这个改动的软件新版本发布上线。这需要多久？可能需要几秒，也可能需要数个星期甚至更长的时间。本书介绍在保证一定发布质量的前提下，如何加速这个过程，让它尽量快一点儿，同时让我们投入的精力尽量少一点儿。也就是说，本书介绍如何让软件交付变得更高效。软件工程、敏捷、精益、持续集成、持续交付、DevOps、云原生、研发效能、平台工程等，都对这个话题有所贡献。本书并不囿于上述某个特定的“门派”，而是介绍它们的关键要点，介绍如何综合运用它们，并且根据实践有所发展。

作者介绍

董越，独立DevOps咨询师、《软件交付通识》等书作者、《DevOps实践指南》（第2版）等书译者。曾任阿里巴巴集团研发效能事业部架构师、高级产品专家等职，从事Aone/云效DevOps产品设计、阿里云专有云集成与发布解决方案设计等工作。在加入阿里巴巴之前，还曾就职于西门子、摩托罗拉、雅虎、索尼、去哪儿网等大型企业，一直从事软件配置管理、持续集成/持续交付、DevOps、软件研发交付效能相关的工作。当前主要从事企业级DevOps体系建设的咨询和培训工作，帮助华为、中国工商银行、交通银行、招商银行、中信银行、中国移动、中国联通、中国电信、华泰证券、泰康人寿等众多企业提升软件研发交付效能。牛晓玲，中国信息通信研究院云计算与大数据研究所审计与治理部副主任，DevOps标准工作组组长，DevOps国际标准编辑人。长期从事开发运维方面的研究工作，包括云服务的运维管理系统审查等相关工作。参与编制《云计算服务协议参考框架》、《对象存储》、《云数据库》、《研发运营一体化（DevOps）能力成熟度模型》系列标准和《云计算运维智能化通用评估方法》等标准20余项。参与多本白皮书、多份调查报告等的编写工作，包括《企业IT运维发展白皮书》、《中国DevOps现状调查报告（2019）》、《中国DevOps现状调查报告（2020）》和《中国DevOps现状调查报告（2021）》等。参与DevOps能力成熟度评估超过50个项目，具有丰富的标准编制及评估测试经验。茹炳晟，腾讯Tech Lead，腾讯研究院特约研究员，中国计算机学会（CCF）TF研发效能SIG主席，《软件研发效能度量规范》标准核心编写专家，中国商业联合会互联网应用技术委员会智库专家，中国通信标准化协会TC608云计算标准和开源推进委员会云上软件工程工作组副组长，多本技术畅销书作者。著作有《测试工程师全栈技术进阶与实践》、《现代软件测试技术之美》、《软件研发效能提升之美》、《软件研发效能提升实践》、《软件研发效能权威指南》和《多模态大模型：技术原理与实战》等，译作有《持续架构实践》、《DevOps实践指南》（第2版）、《精益DevOps》、和《现代软件工程》等。QCon、SECon、QECon、Archsummit等技术峰会的联席主席、出品人和Keynote演讲嘉宾。微信公众号“茹炳晟聊软件研发”主理人。施景丰，北京华佑科技有限公司技术合伙人，高效运维社区首席咨询师，复旦大学软件学院本科生客座导师，2023服贸会“企业数字化转型论坛”卓越专家，GOPS大会金牌讲师，CI/CD Meetup Online 明星讲师，Certified DevOps Enterprise Coach。曾先后就职于用友软件、中体彩、魅族、美云智数等知名企业并担任技术总监、工程效率专家，主导工程效率体系与平台建设。专注于数字化转型/工程效率/DevOps领域，帮助企业全面提升软件研发效能和数字化能力。石雪峰，京东零售研发效能专家，主导企业级研发效能体系和研发数字化体系建设，开放原子开源基金会TOC成员，知识星球“研发效能”主理人，极客时间专栏《DevOps实战笔记》主笔，《软件研发效能权威指南》、《Jenkins 2权威指南》和《高效能团队模式》等书的译著者。王晓翔，独立DevOps咨询师，《DevOps实践指南》（第2版）译者。去哪儿网工程效率部前高级总监，曾任奇安信内聘顾问，GOPS深圳大会金牌讲师，2019运维行业年度优秀技术专家，《研发运营一体化（DevOps）能力成熟度模型》系列标准咨询师。在软件配置管理、过程管理和工程效率方面有十几年的工作经验。曾在中国海关数据中心、索尼移动通信产品（中国）有限公司等多家公司工作。在去哪儿网任职期间，逐步构建起持续集成、持续交付流水线，形成以应用为中心的全生命周期管理体系，并且通过平台化不断为研发团队赋能，构建去哪儿网企业内部的DevOps生态圈，同时带领团队完成了从传统配置管理到工程效率团队的转型。

目 录

第1部分　推开软件交付之门
第1章　软件交付过程的范围 2
1.1　修改了源代码之后 2
1.2　直到改动发布上线 3
1.3　在软件开发全过程中的位置 4
1.4　为什么要这么划分软件交付过程 5
第2章　软件交付过程的内容 6
2.1　程序改动的累积和汇聚 6
2.2　程序形态的转化 8
2.3　程序质量的提升 10
第3章　软件交付过程的追求目标 13
3.1　整体目标：为了业务的成功 13
3.2　确定需求：有效率地找到有效需求 14
3.3　从确定需求到实现需求：小步快跑 15
3.4　实现需求：效率与质量 16
3.4.1 体现效率：需求吞吐量 16
3.4.2 体现效率：需求响应时长 17
3.4.3 质量不是越高越好 19
3.4.4 体现质量：问题出现量 19
3.4.5 体现质量：问题修复时长 20
3.4.6 要兼顾短期和长期 20
3.4.7 四个象限简介 21
3.5　软件交付过程在四个象限的优化 21
3.5.1 提高需求吞吐量 22
3.5.2 缩短需求响应时长 22
3.5.3 减少问题出现量 23
3.5.4 缩短问题修复时长 24
3.6　DORA的DevOps核心指标 25
第2部分　软件交付总体过程
第4章　持续集成 28
4.1　什么是持续集成 28
4.1.1 什么是持续 28
4.1.2 什么是集成 29
4.2　为什么要持续集成 30
4.2.1 小批量，减少等待 30
4.2.2 问题早发现、早修复，代价小 31
4.2.3 频繁同步以减少冲突 31
4.3　流水线 33
4.3.1 流水线的诞生 33
4.3.2 流水线包含哪些活动 33
4.3.3 流水线的功能 35
第5章　逐特性集成 37
5.1　什么是特性 37
5.2　什么是逐特性集成 38
5.3　仍符合持续集成的理念 39
5.4　隔离未完成特性的其他方法 40
5.5　何时不必考虑隔离未完成的特性 41
5.6　当特性做不到既小又独立时 42
第6章　在集成之前 44
6.1　第四阶段：特性改动提交 44
6.1.1 合并请求基础款：代码评审 44
6.1.2 合并请求增强款：代码评审+流水线 45
6.1.3 在创建合并请求之前 47
6.2　第三阶段：特性改动累积 48
6.3　第二阶段：代码改动提交 49
6.3.1 代码改动通过关卡才出现在目标分支 49
6.3.2 在提交时本地自动进行质量把关 50
6.3.3 在提交代码改动之前 51
6.4　第一阶段：代码改动累积 52
6.4.1 随时进行的质量保证工作 52
6.4.2 实时进行的质量保证工作 53
6.4.3 IDE 54
第7章　持续交付 55
7.1　什么是持续交付 55
7.1.1 持续交付是持续集成的延伸 56
7.1.2 持续是适度频繁 56
7.2　为什么要持续交付 58
7.3　版本晋级机制 59
7.4　部署流水线 61
7.5　迈向持续部署 63
7.5.1 适当的发布频率 63
7.5.2 如何提高发布频率 64
7.5.3 持续部署 65
第8章　特性间进一步解耦 67
8.1　混合自测 67
8.2　特性摘除 68
8.3　混合测试 70
8.4　逐特性交付 73
8.5　特性间解耦方法小结 74
第9章　运用精益思想 76
9.1　限制在制品的数量 76
9.2　优化发布审批 78
9.2.1 什么是发布审批 78
9.2.2 精简发布审批流程 78
9.2.3 发布审批的工具支持 79
9.3　消除发布时间窗口限制 80
第10章　突破Scrum的若干约束 82
10.1　发布版本间的交叠 82
10.2　在一次迭代中多次发布 84
10.3　迭代规划内容不必都做完 85
10.4　特事特办 86
第11章　多项内容协同交付 87
11.1　本书中的微服务是代称 87
11.2　提交完整的特性 88
11.3　采用相同的节奏 89
11.4　特性间完全解耦 90
11.5　按特定的顺序发布 90
第12章　静态库的交付 92
12.1　什么是静态库 92
12.2　作为公共基础库 92
12.3　作为整体应用的组成部分 93
12.4　作为服务接口定义 94
第13章　并行的多个版本序列 96
13.1　版本序列之间的交叠 96
13.2　变体 97
第14章　尽快修复问题 99
14.1　尽快修复流水线的问题 99
14.1.1 为什么要尽快修复 99
14.1.2 自动通知合适的人 100
14.1.3 足够高的优先级 101
14.1.4 足够多的相关信息 101
14.2　尽快修复测试发现的缺陷 102
14.3　尽快解决发布带来的问题 102
14.3.1 系统的可观测性 103
14.3.2 发布回滚 103
14.3.3 紧急发布 104
14.3.4 当紧急程度更低一些时 105
第3部分　程序改动的累积和汇聚
第15章　版本控制 108
15.1　什么是版本控制 108
15.2　实现版本控制的方法和工具 108
15.3　版本命名 109
15.3.1 传统的版本命名方式 110
15.3.2 SaaS软件的版本命名 110
15.3.3 考虑版本控制工具的能力 111
15.3.4 考虑制品管理的方法 112
15.4　分支 112
15.4.1 “现代派”分支 113
15.4.2 制品的分支 113
第16章　使用版本控制工具 114
16.1　版本控制工具简介 114
16.2　代码库内的层次结构 115
16.3　代码库间的层次结构 115
16.4　不应放入代码库的内容 116
16.4.1 小心二进制文件 116
16.4.2 代码库二进制文件存储方案 117
16.4.3 不应纳入版本控制的内容 117
16.5　代码改动与工作项间的关联 118
16.5.1 将代码改动提交记录关联到工作项 118
16.5.2 将特性的代码改动提交记录关联到工作项 119
16.6　版本与工作项间的关联 120
16.6.1 送测特性列表 120
16.6.2 发布特性列表与发布说明 121
16.7　代码库的体积 121
第17章　分支策略 123
17.1　分支的四个层级 123
17.2　生产级分支 124
17.3　集成级分支 125
17.3.1 支持交叠：长集成分支+短发布分支 126
17.3.2 支持交叠：长集成分支+长发布分支 127
17.3.3 支持交叠：短集成发布分支 127
17.3.4 支持混合自测与测试：长环境分支 129
17.3.5 支持混合自测与测试：短环境分支 130
17.3.6 支持特性单独测试和发布 131
17.4　特性级分支 132
17.4.1 特性分支从哪里创建、从哪里同步 132
17.4.2 合入集成级分支时处理冲突的方法 133
17.4.3 在已提交的特性上继续改动 134
17.4.4 如何摘除特性 135
17.4.5 何时删除特性分支 136
17.5　版本序列级分支 136
17.5.1 支持多个版本序列间的交叠 137
17.5.2 支持多个变体 138
17.6　典型分支策略分析 139
17.6.1 Git Flow 140
17.6.2 GitHub Flow 141
17.6.3 GitLab Flow 141
17.6.4 Aone Flow 143
第18章　使用制品管理工具 144
18.1　制品、制品库与制品管理工具 144
18.2　“正式”制品必须来自流水线上的构建 145
18.3　制品库间的层次结构 145
18.4　制品库内的层次结构 146
18.5　记录制品的属性信息 147
18.6　避免重复存储 147
18.7　制品的尺寸 148
18.8　加速制品存取的方法 149
18.9　制品清理策略 149
第4部分　程序形态的转化
第19章　构建 152
19.1　什么是构建 152
19.2　构建的可重复性 153
19.2.1 构建的原材料不变 153
19.2.2 构建的工具和方法不变 154
19.3　加速构建 154
19.3.1 基本方法 155
19.3.2 探索：从程序形态转化全过程的视角优化 156
19.3.3 探索：一些高端方法 157
19.4　源代码、构建、制品之间的关联关系 158
第20章　构建环境 160
20.1　什么是构建环境 160
20.2　构建环境标准化 160
20.3　构建环境资源池化 161
20.3.1 构建环境资源池化的价值 161
20.3.2 保障构建所需缓存 162
第21章　部署 164
21.1　自动化部署 164
21.2　部署策略 165
21.2.1 生产环境的部署策略 165
21.2.2 测试环境的部署策略 167
21.2.3 客户端的部署策略 167
21.3　判断部署成功完成的方法 168
21.4　发布与部署分离 168
21.5　快速回滚 169
21.6　制品、部署、环境之间的关联关系 170
第22章　运行环境 171
22.1　什么是运行环境 171
22.2　运行环境管理的内容 172
22.3　管理本地运行环境 172
22.3.1 声明式 173
22.3.2 只换不修 173
22.4　让微服务在整体运行环境中运行 174
22.4.1 资源的申请与实现 174
22.4.2 基础设施即代码与GitOps 174
22.4.3 封装以降低认知负荷 175
22.5　管理整套环境 175
22.5.1 何时需要再搭建一套环境 175
22.5.2 整套环境的自动生成与分配 176
22.5.3 实现在整体系统中自测 177
22.5.4 探索：虚拟独占方式 178
22.5.5 测试环境和生产环境的一致性 179
22.5.6 数据隔离 180
第23章　SQL变更 181
23.1　什么是SQL变更 181
23.2　自动执行SQL变更 182
23.3　确保SQL变更质量 182
23.4　程序与数据存储结构的版本匹配 183
23.5　管理SQL变更的特别之处 183
23.5.1 管理SQL变更的挑战 184
23.5.2 应对挑战的常见方法 184
23.5.3 探索：声明式 185
第24章　应用配置参数 187
24.1　什么是应用配置参数 187
24.2　应用配置参数的管理 188
24.3　如何设置应用配置参数 188
24.3.1 设置应用配置参数的方式 189
24.3.2 自动执行 189
24.3.3 设置方式的选择 190
24.3.4 探索：键值分离 191
24.3.5 探索：减少人工设置内容 193
24.4　质量和安全 193
24.4.1 确保变更质量 193
24.4.2 程序与应用配置参数的版本匹配 194
24.4.3 敏感信息管理 195
第5部分　程序质量的提升
第25章　静态测试 198
25.1　代码扫描 198
25.1.1 什么情况下要做代码扫描 198
25.1.2 什么时候做代码扫描 199
25.1.3 必要时定制规则 200
25.2　代码评审 200
25.2.1 什么情况下要做代码评审 200
25.2.2 代码评审的颗粒度 201
25.2.3 事前评审和事后评审 202
25.2.4 代码评审的形式 203
25.2.5 代码评审的内容 205
25.2.6 代码评审的方法：检查清单 206
25.2.7 探索：代码评审时更方便地查看相关代码 206
25.3　软件成分分析 207
25.3.1 什么情况下要做软件成分分析 207
25.3.2 什么时候做软件成分分析 208
第26章　动态测试 209
26.1　单元测试 209
26.1.1 什么情况下要做单元测试 210
26.1.2 什么时候做单元测试 210
26.2　接口自动化测试 211
26.2.1 接口自动化测试的内容 211
26.2.2 什么情况下要做接口自动化测试 211
26.2.3 什么时候做接口自动化测试 212
26.2.4 探索：接口只在一处定义一次 213
26.2.5 流量回放 213
26.3　UI自动化测试 214
26.3.1 什么情况下要做UI自动化测试 214
26.3.2 什么时候做UI自动化测试 215
26.3.3 录制还是编写 215
26.4　人工功能测试 216
26.4.1 什么情况下要做人工功能测试 216
26.4.2 什么时候做人工功能测试 217
26.4.3 探索性测试 217
第27章　重要但容易被忽略的测试 218
27.1　非功能测试 218
27.1.1 测试内容：性能和容量 218
27.1.2 测试内容：安全性 219
27.1.3 测试内容：兼容性 220
27.1.4 测试内容：易用性 220
27.1.5 什么时候做非功能测试 220
27.1.6 尽可能自动执行 221
27.2　生产环境测试 221
27.2.1 先在小范围试用 221
27.2.2 发布后的功能测试 223
27.2.3 生产环境中的非功能测试 223
第28章　测试通用要点 225
28.1　程序的输入：应对无尽的可能性 225
28.1.1 正常、异常和边界情况 225
28.1.2 使用等价类来应对 226
28.1.3 输入数据不只是函数的输入参数 226
28.1.4 组合爆炸 227
28.1.5 测试覆盖率 227
28.1.6 用好测试覆盖率 228
28.2　程序的输出：怎样写断言 229
28.2.1 程序输出的多种形式 229
28.2.2 对输出进行适当的校验 229
28.3　测试数据准备 230
28.4　测试用例间的隔离性 231
28.4.1 防止干扰 231
28.4.2 管理测试用例间依赖 232
28.5　如何更快地编写和维护测试脚本与数据 233
28.5.1 测试脚本的分层与复用 233
28.5.2 测试脚本与数据相分离 233
28.5.3 测试数据的分层与复用 234
28.5.4 探索：测试脚本的自动化生成 234
28.6　快速执行测试 235
28.7　探索：测试驱动开发及其变体 236
28.8　从人员和组织管理角度保障测试投入 237
28.9　提升人员的测试能力 237
第29章　测试通用策略 239
29.1　工作量在不同测试中的分配 239
29.2　根据场景选择合适的测试力度 240
29.3　测试时机和频率 242
29.4　增量优先 244
29.4.1 优先为增量代码改动准备测试脚本和用例 244
29.4.2 优先执行增量代码改动相关测试 244
29.4.3 优先解决增量代码改动相关问题 245
29.5　技术债：在必要时欠债 246
29.6　质量门禁：有原则有灵活性 248
29.6.1 质量门禁可以适当通融 248
29.6.2 考虑定制质量门禁规则 249
29.6.3 考虑忽略某些代码 249
29.7　Mock还是不Mock，这是个问题 250
29.7.1 单元测试尽可能使用Mock 250
29.7.2 尽量在完整系统中进行其他测试 251
29.7.3 仅在必要时使用Mock 251
29.8　质量反馈驱动测试改进 252
第30章　缺陷修复 255
30.1　管理缺陷 255
30.1.1 跟踪缺陷的方法 255
30.1.2 记录缺陷相关信息 256
30.2　需求、测试、缺陷之间的关联关系 257
30.2.1 自动化测试时 257
30.2.2 人工测试时 259
30.3　调试工具 259
30.3.1 调试器 260
30.3.2 接口调试工具 260
30.3.3 UI调试工具 260
30.3.4 探索：复现运行上下文 260
30.4　测试环境的环境问题 261
30.4.1 减少测试环境的环境问题 261
30.4.2 探索：失败原因自动分类 262
第6部分　杂谈
第31章　组织结构与人员职责 264
31.1　项目制还是产品制 264
31.2　全功能团队还是职能团队 265
31.3　团队的规模 267
31.4　团队内部分工：谁做测试 267
31.5　团队间解耦 269
31.6　按业务功能划分并考虑软件复用 270
31.7　组织的层级结构 270
31.8　组织级支持 271
第32章　平台工程：工具平台的建设和维护 273
32.1　什么是平台工程 273
32.2　使用工具代替专职人员的重复操作 273
32.3　平台工程的核心是便捷易用 275
32.4　一体化的工具平台 275
32.5　拿来主义还是自主研制 276
32.6　方案收敛 277
32.7　适当宽松的权限策略 278
32.8　工具可用性 279
第33章　终章：软件交付10策略 281
33.1　小批量持续流动 281
33.1.1 大批量带来等待等问题 281
33.1.2 短周期、小颗粒度、减少半成品 282
33.1.3 小批量持续流动的交付过程 283
33.2　运用综合手段保证质量和安全 283
33.2.1 各种各样的测试 284
33.2.2 左移+右移 284
33.2.3 开发人员+测试人员 285
33.2.4 自动化测试+人工测试 285
33.2.5 综合运用 285
33.3　细粒度、低耦合、可复用的架构 286
33.3.1 软件架构 286
33.3.2 测试脚本和测试数据的架构 287
33.3.3 组织架构 287
33.4　自动化与自助化 289
33.4.1 单项活动的自动化 289
33.4.2 流程的自动化 289
33.4.3 自助化 290
33.4.4 相关支持 290
33.5　加速各项活动 290
33.6　及时修复 292
33.6.1 为什么要及时修复 292
33.6.2 如何做到及时修复 292
33.7　完备记录，便捷查阅 293
33.7.1 跟踪事项，记录执行 294
33.7.2 版本控制 294
33.7.3 关联关系 295
33.8　标准化和一致性 296
33.8.1 规范可重复 296
33.8.2 方案收敛 297
33.8.3 环境一致性 297
33.9　协调完成完整功能 298
33.9.1 背景 298
33.9.2 开发全过程的协调 299
33.9.3 软件交付过程的协调 299
33.10　基于事实和数据的持续改进 300
33.11　总结 301
附录A　数十年来的探索 302
附录B　各类内容的版本控制方式 314