新書推薦：
《
收尸人
》
售價：NT$
332.0
《
大模型应用开发：RAG入门与实战
》
售價：NT$
407.0
《
不挨饿快速瘦的减脂餐
》
售價：NT$
305.0
《
形而上学与存在论之间：费希特知识学研究（守望者）（德国古典哲学研究译丛）
》
售價：NT$
504.0
《
卫宫家今天的饭9 附画集特装版（含漫画1本+画集1本+卫宫士郎购物清单2张+特制相卡1张）
》
售價：NT$
602.0
《
化妆品学原理
》
售價：NT$
254.0
《
万千教育学前·与幼儿一起解决问题：捕捉幼儿园一日生活中的教育契机
》
售價：NT$
214.0
《
爱你，是我做过最好的事
》
售價：NT$
254.0
|
| 內容簡介： |
|
这是一本介绍软件交付过程的“科普小册子”。软件交付过程是指修改了一行源代码之后的一系列工作，直到包含这个改动的软件新版本发布上线。这需要多久？可能需要几秒，也可能需要数个星期甚至更长的时间。本书介绍在保证一定发布质量的前提下，如何加速这个过程，让它尽量快一点儿，同时让我们投入的精力尽量少一点儿。也就是说，本书介绍如何让软件交付变得更高效。软件工程、敏捷、精益、持续集成、持续交付、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 必
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
