持续交付图解

第Ⅰ部分　持续交付入门1
第1章　欢迎阅读本书3
1.1　你需要持续交付吗4
1.2　为什么要持续交付5
1.3　持续交付7
1.4　集成8
1.5　持续集成9
1.6　我们能交付什么10
1.7　交付11
1.8　持续交付/持续部署12
1.9　持续交付的要素13
1.10　结论14
1.11　本章小结14
1.12　接下来……14
第2章　基础流水线15
2.1　猫咪图片网站16
2.2　猫咪图片网站源码17
2.3　猫咪图片网站流水线18
2.4　什么是流水线，什么是任务19
2.5　CD流水线中的基础任务20
2.6　门禁与转换21
2.7　CD：门禁机制与转换22
2.8　猫咪图片网站服务流水线23
2.9　运行流水线24
2.10　每天都运行一次25
2.11　尝试持续集成26
2.12　使用通知27
2.13　拓展手动工作28
2.14　通过webhook自动化29
2.15　拓展webhook30
2.16　在流水线出现问题时不要提交代码变更31
2.17　猫咪图片网站的CD32
2.18　名称中的学问33
2.19　结论34
2.20　本章小结34
2.21　接下来……34
第Ⅱ部分　让软件一直保持在可交付状态35
第3章　版本控制是发布软件的唯一方式37
3.1　Sasha和Sarah的创业38
3.2　所有类型的数据39
3.3　源码与软件40
3.4　代码库和版本41
3.5　持续交付和版本控制42
3.6　Git和GitHub43
3.7　第一次代码提交——出错啦44
3.8　主分支出错45
3.9　推送与拉取46
3.10　我们在进行持续交付吗48
3.11　让版本控制系统保持可发布状态49
3.12　代码变更提交到版本控制系统时的触发器50
3.13　触发用户服务流水线51
3.14　构建用户服务52
3.15　云端的用户服务53
3.16　连接RandomCloud数据库54
3.17　管理用户服务55
3.18　用户服务宕机56
3.19　被自动化打败57
3.20　什么是可信代码源58
3.21　用户服务的配置即代码60
3.22　配置Deployaker62
3.23　配置即代码63
3.24　发布软件与配置变更64
3.25　结论66
3.26　本章小结66
3.27　接下来……66
第4章　有效使用静态代码检查67
4.1　Becky和超级游戏控制台68
4.2　采用静态代码检查解决问题69
4.3　关于静态代码检查的内幕70
4.4　Pylint的故事和很多问题71
4.5　遗留代码：使用系统化方法72
4.6　第1步：根据编码规范进行配置73
4.7　第2步：建立基线74
4.8　第3步：在提交时强制执行75
4.9　向流水线添加强制执行76
4.10　第4步：分而治之77
4.11　隔离：不是所有问题都应该修复78
4.12　强制隔离79
4.13　并非所有问题都同等重要80
4.14　静态代码检查问题的类型81
4.15　缺陷优先，风格其后82
4.16　克服重重障碍83
4.17　结论85
4.18　本章小结85
4.19　接下来……85
第5章　处理有噪声的测试87
5.1　持续交付和测试88
5.2　“全民冰淇淋”停机事件89
5.3　信号与噪声90
5.4　噪声的成功91
5.5　失败是如何变成噪声的92
5.6　从噪声到信号94
5.7　让测试通过(变绿)95
5.8　又一次停机96
5.9　通过测试仍然可能会有噪声97
5.10　修复测试失败98
5.11　失败的方式：脆弱的测试99
5.12　对失败做出反应100
5.13　修复测试：修改代码或测试101
5.14　重试的危险102
5.15　重试重新访问103
5.16　为什么要重试105
5.17　变绿并保持绿色106
5.18　结论108
5.19　本章小结108
5.20　接下来……108
第6章　让那些缓慢的测试套件变得更快109
6.1　狗狗图片网站110
6.2　当流水线过于简单时111
6.3　新工程师试图提交代码112
6.4　测试和持续交付113
6.5　诊断：速度太慢114
6.6　测试金字塔115
6.7　先运行执行快的测试用例116
6.8　两条流水线117
6.9　获得正确的平衡118
6.10　改变金字塔比例119
6.11　安全地调整测试用例120
6.12　测试覆盖率121
6.13　强制要求测试覆盖率122
6.14　流水线中的测试覆盖率123
6.15　在具备覆盖率的金字塔中移动测试用例124
6.16　沿着金字塔往下移动什么125
6.17　遗留的测试用例和FUD127
6.18　并行运行测试用例128
6.19　何时可以并行运行测试用例129
6.20　更新流水线130
6.21　还是太慢了131
6.22　分片测试，又称并行 132
6.23　如何分片133
6.24　更复杂的分片134
6.25　分片流水线135
6.26　对浏览器测试套件进行分片136
6.27　流水线中的分片137
6.28　狗狗图片网站的流水线138
6.29　结论142
6.30　本章小结142
6.31　接下来……142
第7章　在正确的时间发出正确的信号143
7.1　CoinExCompare网站144
7.2　代码变更的生命周期145
7.3　仅在代码合并前进行的CI146
7.4　代码变更出错的时间线147
7.5　仅在合并前运行的CI未命中缺陷148
7.6　两张图的故事：默认为7天149
7.7　两张图的故事：默认为30天150
7.8　冲突并不是总会被发现151
7.9　单元测试呢152
7.10　PR触发器仍然会让缺陷潜入153
7.11　合并前以及合并后的CI154
7.12　选项1：定期运行CI155
7.13　选项1：设置定期运行的CI156
7.14　选项2：要求特性分支是最新的157
7.15　选项2：成本是多少158
7.16　选项3：自动合并CI159
7.17　选项3：使用最新的主分支运行CI160
7.18　选项3：合并事件161
7.19　选项3：合并队列162
7.20　选项3：CoinExCompare网站的合并队列163
7.21　哪里还会发生错误165
7.22　测试脆弱性和PR触发的CI166
7.23　通过定期测试捕获脆弱的测试167
7.24　缺陷和构建168
7.25　CI与构建和部署169
7.26　使用相同的逻辑构建和部署170
7.27　通过构建改进CI流水线171
7.28　重新审视代码变更时间表172
7.29　结论174
7.30　本章小结174
7.31　接下来……174
第Ⅲ部分　让交付变得简单175
第8章　轻松交付从版本控制出发177
8.1　回到Watch Me Watch项目178
8.2　DORA指标179
8.3　如果我不运行服务呢181
8.4　Watch Me Watch 与精英效能团队183
8.5　给Watch Me Watch提升速率184
8.6　与AllCatsAllTheTime集成 185
8.7　主干开发186
8.8　特性增量式交付187
8.9　跳过测试的提交188
8.10　代码评审和“不完整”的代码189
8.11　保持这个势头191
8.12　提交不完整的代码192
8.13　评审进行中的代码193
8.14　与此同时，让我们回到端到端测试194
8.15　可见的好处195
8.16　不断缩短的变更前置时间197
8.17　继续AllCatsAllTheTime开发198
8.18　部署窗口和代码冻结199
8.19　速率提高200
8.20　结论201
8.21　本章小结201
8.22　接下来……201
第9章　安全可靠的构建203
9.1　Top Dog Maps204
9.2　当构建流程仅仅记录在文档中时205
9.3　安全和可靠构建的属性206
9.4　始终可发布208
9.5　自动化构建209
9.6　构建即代码210
9.7　使用CD服务211
9.8　临时构建环境212
9.9　Miguel的计划213
9.10　从纯文档到拥有版本控制的脚本 214
9.11　自动化容器化构建215
9.12　安全和可靠的构建流程217
9.13　接口的变更和导致的缺陷219
9.14　当构建产生缺陷时220
9.15　构建与沟通221
9.16　语义化版本控制222
9.17　版本控制的重要性223
9.18　又一次故障！225
9.19　构建时依赖导致的错误226
9.20　锁定依赖项版本227
9.21　仅仅锁定版本还不足够228
9.22　锁定哈希值229
9.23　结论231
9.24　本章小结231
9.25　接下来……231
第10章　可信赖的部署233
10.1　部署困扰不断234
10.2　DORA的稳定性指标235
10.3　Plenty of Woofs的DORA指标237
10.4　减少部署频率吗238
10.5　增加部署频率吗239
10.6　每日部署与故障240
10.7　增加部署频率的步骤241
10.8　修复流程中的问题242
10.9　滚动更新243
10.10　通过滚动更新修复缺陷244
10.11　回滚245
10.12　回滚策略 = 即时改善246
10.13　回滚策略实战248
10.14　蓝绿部署249
10.15　使用蓝绿部署加速故障恢复时间250
10.16　金丝雀发布更快且更稳定251
10.17　金丝雀部署的前提条件252
10.18　金丝雀发布的基线254
10.19　金丝雀发布的服务恢复时间255
10.20　增加部署频率257
10.21　每日金丝雀发布策略下的DORA指标258
10.22　持续部署259
10.23　使用持续部署的时机260
10.24　强制性的QA阶段261
10.25　QA与持续部署262
10.26　精英效能团队264
10.27　结论265
10.28　本章小结265
10.29　接下来……265
第Ⅳ部分　设计持续交付267
第11章　启动包：从零到CD269
11.1　启动包：概览270
11.2　回顾：通用的CD流水线任务271
11.3　典型的发布流水线272
11.4　典型的CI流水线273
11.5　两条都带触发器的流水线274
11.6　绿地项目：迈向CD276
11.7　Gulpy277
11.8　绿地项目：从零到CD278
11.9　第一步：它能构建吗279
11.10　选择CD系统280
11.11　建立初始的自动化281
11.12　代码的状态：静态代码检查282
11.13　代码的状态：单元测试283
11.14　代码的状态：覆盖率284
11.15　超越CI：发布285
11.16　部署286
11.17　扩展测试287
11.18　集成测试和端到端测试的任务288
11.19　完成CI流水线289
11.20　Gulpy完整的流水线290
11.21　遗留项目：迈向CD291
11.22　Rebellious Hamster292
11.23　第一步：确定增量目标的优先级293
11.24　首先关注痛点294
11.25　Rebellious Hamster的痛点295
11.26　知道何时出现了问题296
11.27　隔离并添加测试297
11.28　具有更多测试的遗留项目流水线298
11.29　使部署更加自动化299
11.30　创建发布流水线300
11.31　Rebellious Hamster的发布流水线301
11.32　Rebellious Hamster的完整流水线302
11.33　结论303
11.34　本章小结303
11.35　接下来……303
第12章　脚本也是代码305
12.1　Purrfect Bank306
12.2　CD的问题307
12.3　Purrfect Bank的CD概览308
12.4　支付组织的Bash脚本库309
12.5　交易服务流水线310
12.6　从一个大脚本演化311
12.7　设计良好任务的原则312
12.8　打破巨型任务313
12.9　更新后的交易服务流水线314
12.10　调试Bash库315
12.11　调查Bash库的缺陷316
12.12　为什么会引入这个缺陷317
12.13　Bash的作用318
12.14　何时Bash不太好319
12.15　shell脚本与通用语言321
12.16　从shell脚本到通用编程语言322
12.17　迁移计划323
12.18　从Bash库到拥有Bash的任务324
12.19　任务内的可重用Bash325
12.20　从Bash到Python326
12.21　任务即代码327
12.22　CD脚本也是代码328
12.23　结论329
12.24　本章小结329
12.25　接下来……329
第13章　流水线设计331
13.1　PetMatch332
13.2　匹配服务CD流水线333
13.3　CD流水线问题334
13.4　端到端测试流水线335
13.5　端到端测试流水线和错误336
13.6　最终行为337
13.7　图形化最终部分338
13.8　匹配服务流水线中的最终行为339
13.9　端到端测试流水线和速度340
13.10　并行执行任务341
13.11　端到端测试流水线和测试速度342
13.12　并行执行和测试分片343
13.13　带有分片的端到端测试流水线344
13.14　端到端测试流水线和信号345
13.15　单一CI流水线346
13.16　发布流水线与信号347
13.17　CI流水线的差异348
13.18　合并流水线349
13.19　发布流水线350
13.20　发布流水线中的硬编码351
13.21　通过参数化复用流水线352
13.22　使用可重用的流水线353
13.23　更新后的流水线354
13.24　解决PetMatch的CD问题355
13.25　期待的CD功能356
13.26　结论357
13.27　本章小结357
13.28　接下来……357
附录359
附录A　 -- CD系统361
附录B　-- 版本控制系统371