新書推薦：
《
英国教育史研究丛书——延续与新变：英国斯图亚特时期贵族教育研究
》
售價：HK$
108.9
《
更易上手！钢琴弹唱经典老歌（五线谱版）
》
售價：HK$
54.8
《
哲学叙事：中国与西方
》
售價：HK$
107.8
《
一人商业模式 创富新路径个人经济自由创业变现方法书
》
售價：HK$
54.8
《
经典与想象：中国古代传说新解
》
售價：HK$
85.8
《
祠堂与教堂：中西传统核心价值观比较研究（第3版）
》
售價：HK$
118.8
《
极简德国东方看世界·极简德国史
》
售價：HK$
74.8
《
舌尖上的中国新编视频版营养师妈妈教你做婴幼儿餐
》
售價：HK$
63.8
|
| 編輯推薦： |
|
《持续交付图解》是大型软件研发从业者经验传授的经典著作，Christie从MVP故事出发，利用敏捷迭代的方法将持续集成、持续构建、持续交付等复杂的概念融入全书的叙述中。难能可贵的是，这些方法均巧妙地集成到了一个创业公司不断升级打怪的故事中，作者的叙述让每位读者不仅知其然且知其所以然，我想这就是本书最难能可贵的价值。这些重要概念的上下文才是诸位看官决定是否采纳，以及如何采纳那些当下流行技术词汇的重要依据。
|
| 內容簡介： |
请让你的代码库随时保持可发布状态。持续交付流水线可以实现自动化版本控制、自动测试和自动部署，将开发人员的干预降至最低。掌握持续交付的工具和实践，你将能够快速且一致地添加功能和推送更新。
《持续交付图解》是建立和使用持续交付流水线的友好指南。每一章都介绍了在设置CD系统时将面临的不同场景，包括自动扩展和测试遗留应用程序等现实问题的示例。作者Christie Wilson采用与具体工具无关的方法，通过插图、清晰的解释和实践练习来指导你的每一步学习。
主要内容
?为新项目和遗留项目设计有效的CD流水线
?确保你的流水线在适当的时候发出正确的信号
?将版本控制作为真相的来源
?安全地自动化部署
|
| 關於作者： |
Christie Wilson是一名软件工程师。她经常在Kubecon、OSCON、QCon、PyCon等会议上就CI/CD及相关主题发表演讲。Christie的职业生涯始于移动端Web应用开发。在从事AAA游戏的后端开发时，她编写的功能通常在系统大规模发布后才会被许多人同时使用。为此，她构建了负载和系统测试平台。
凭借处理复杂部署环境、核心关键系统和应对突发流量的经验，她加入了Google并从事相关方向的工作。在Google，她为AppEngine、boot-strapped Knative构建了内部生产力工具，并创建了Tekton，这是一个基于Kubernetes(目前有65家以上的公司参与)构建的云原生CI/CD平台。
|
| 目錄：
|
第Ⅰ部分 持续交付入门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
|
| 內容試閱：
|
序 言
当我和David Farley合著Continuous Delivery: Reliable Software Releases through Build， Test， and Deployment Automation (Addison-Wesley，2010)一书时，我们认为书中描述的我们多年实践的原则“一种现代的、整体的软件交付方法”会为使用它的团队和组织带来巨大好处。多个研究项目(包括我参与的由Nicole Forsgren博士主导，并在本书第8章和第10章描述的项目)表明，它可以带来更高的质量和稳定性，以及更快的交付速度。
尽管持续集成和持续交付(Continuous Integration and Continuous Delivery，CI/CD)现在已成为行业标准的做法实践，但是仍然十分难以落地。仍有许多团队(还有客户)需要处理晚上或周末等休息时间偶发的、有风险的发布，计划内和计划外的停机、回滚，以及性能、可靠性、安全性等方面的问题。这些问题其实是可以避免的，但是要解决这些问题需要在团队、工具和组织文化方面持续投资。
至关重要的是，许多刚进入这个行业的人不熟悉基本的实践以及如何将这些做法落地。本书在解决这个问题上做了出色的工作。Christie Wilson是持续交付方面的专家，在Google领导开源Tekton CI/CD项目，曾撰写过一本全面、清晰且深入的书，描述了实现现代软件交付过程的相关技术与细节。她不仅讲述了理论和实践，还展示了它们为什么重要，并提供了步骤指南来解决那些大家正在努力攻关的难题，例如采用迭代方法，同时进行新特性开发和“遗留”代码处理。
我希望本书能作为入门读物出现在每个软件团队新初级员工的入职阅读书清单中。对于那些更有经验的软件工程师来说，采用不熟悉的工作方式时，这本书也将被证明是宝贵的详细指南。我很感谢Christie创建了这一优秀资源，我相信它将推动人们更好地理解如何实现一个现代软件的交付过程，从而使我们服务的行业和更广泛的公众从中受益。
—— Jez Humble
Continuous Delivery、The DevOps Handbook与Accelerate的合著者
软件的美妙之处在于一切都可随时间的推移而改进。但这也是软件的诅咒——因为我们可以改变它，所以我们几乎一直在改变。对新特性或其他特性进行改进的持续压力，使我们渴望以高效的方式集成代码变更、测试变更，并将其发布给用户。
Christie Wilson经历了这个过程，并从多个角度观察该问题。她写了一本如何让软件团队保持高效的书。如果一个团队能通过自动化实现高效研发，那么其产品就会具有一定的竞争优势。随着时间的推移，这些团队不仅获得了市场份额，而且士气更高，离职率更低。能成为高效团队的一员真是太棒了！
一个常见的误解是，速度较低的软件流程，可能因为有更多的部署障碍而更加安全。例如，许多团队反对变更，因此每个季度发布一次变更。这种方法存在两个严重的缺陷。首先，通常会将集成大量代码变更的困难任务推到最后，但是如果上一个版本遗留了大量的代码需要集成，就可能出现可怕的错误并导致严重的交付延迟。其次，慢交付过程会阻碍快速集成安全补丁，而这本是大多数团队的关键目标。本书中描述的方法都是关于持续的(小)集成的，这既能对问题进行快速反馈，又能为修补安全问题提供可行的机制。
在过去几年，围绕软件供应链进行的攻击，导致安全挑战急剧攀升，现代软件包含了许多三方组件——来自其他团队、其他公司和开源软件。需要将1000个组件集成在一起的事儿并不罕见。这需要不同程度的自动化：需要知道所有的组件来源，以及它们是如何集成在一起的。《持续交付图解》是第一本涵盖这些问题，并概括如何为系统提升安全性的书籍。
最后，虽然在这个领域中有大量的工具可供选择，但本书在涵盖关键概念和目标方面做得很好，同时通过例子和对替代方案的讨论帮助你实现目标。我发现这本书是复杂时空中的一股清风，我希望你也会喜欢它。
—— Eric Brewer
Google院士兼基础设施副总裁
前 言
自从我意识到编程是一件了不起的事后，它就让我着迷。我记得(许多年前)一个朋友告诉我他写了一个国际象棋程序，虽然当时我完全不知道他在说什么，但我同时在想：(a)我从未思考过计算机的工作原理；(b)我现在确实需要尽可能了解它们。接下来的事情或令人惊叹，或令人困惑(“变量就像一个邮箱”是一个在事后看来非常合理的类比，但当我第一次有这个想法时，它只是从我的脑中闪过)。自从我在高中的第一堂Turbo Pascal课和自学Java之后，我就迷上了编程。
尽管我发现编程本身很吸引人，但我对软件开发过程同样感兴趣。在我的职业生涯中，至少有一半时间都因这些过程得到的关注如此之少而失望。软件开发过程不仅对软件质量有影响，还会影响研发人员的心情和工作效率。不仅如此，每当遇到轻视这项工作的工程师和管理者时，我也会感到沮丧。这通常是被尽快写出代码才是对投资的最好回报的观点所驱使。
具有讽刺意味的是，时间和研究表明速度确实是成功的关键指标，但要真正让工程师的工作变得更快并且可持续，速度必须与安全保持平衡。同时最大化软件开发的速度和安全性才是持续交付的核心，这个概念和相关实践引起了我的共鸣。也可以这么说，直到最近我才意识到什么才是持续交付的本质。
首先吸引我的是测试和自动化。我仍然记得第一次接触测试驱动开发(Test-Driven Development，TDD)这个概念时，我体验到一种自由感，意识到居然在开发软件的同时还可以验证它。能够边开发边检查代码，就像卸下了肩上的一个巨大的重担——具体来说，我脑海中的声音有时说：我不知道我在做什么，我写的东西都无法正常工作。而工具和自动化能够帮助我在承担重要工作时保持自信：使用它们就像有一个朋友坐在我身边，指导我的工作。
持续交付作为一个概念，集测试和自动化的精华于一身，这些方法在职业生涯中让我获益良多。此外，持续交付将概念打包成一套实践，可以帮助大家改进开发软件的方式。我想帮助那些有时自我怀疑或与恐惧斗争的工程师(我猜大多数人至少有时会这样)——使他们能感受到我第一次编写测试用例时的那种自由、有力和自信。
感谢你花时间阅读本书。我希望你在看完本书后至少可以领悟到软件的大多数缺陷和错误与代码本身并没有什么关系(当然，也与代码编写者没有关系)。真正导致这些缺陷和错误的软件开发流程，需要一些TLC(Tender Love Care，温柔体贴的关怀)。
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
