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

  • 书籍语言:简体中文
  • 下载次数:3032
  • 书籍类型:Epub+Txt+pdf+mobi
  • 创建日期:2024-10-22 15:10:02
  • 发布日期:2025-09-06
  • 连载状态:全集
  • 书籍作者:董越
  • 运行环境:pc/安卓/iPhone/iPad/Kindle/平板

内容简介

这是一本介绍软件交付过程的“科普小册子”。

软件交付过程是指修改了一行源代码之后的一系列工作,直到包含这个改动的软件新版本发布上线。这需要多久?可能需要几秒,也可能需要数个星期甚至更长的时间。本书介绍在保证一定发布质量的前提下,如何加速这个过程,让它尽量快一点儿,同时让我们投入的精力尽量少一点儿。也就是说,本书介绍如何让软件交付变得更高效。

软件工程、敏捷、精益、持续集成、持续交付、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生态圈,同时带领团队完成了从传统配置管理到工程效率团队的转型。


编辑推荐

集阿里、信通院、腾讯、高效运维社区、京东、DevOps 标准制定者各方面专家之大成,聚持续集成、持续交付、敏捷、精益等软件工程类经典理念之精髓。

数字化和 AIGC时代,DevOps 有了一种全新可能,可以打破原有的低质效平衡,将高质高效进行到底,将交付活动尚在沉没的30%经济效益彻底挖掘干净。

本书面向 IT 行业的所有技术岗位,包括架构、开发、测试和运维等,同时也非常便于学生群体或普通人快速愉悦全面地了解这一现代社会重要的生产活动。

打破云原生、研发效能、平台工程、CI/CD 等各种工程理念的界限,博采众长,融会贯通,务实而不可思议地大幅压缩从源码到上线的时间周期和人力占用。

下载地址

序言

推荐序

互联网行业盛行的急速交付,其实不一定是广大“传统”企业的第一刚需,这从“集成于流水线并被强制频繁执行的质量门禁”成为金融名企的最爱之一,便可见一斑。高质效的交付才是“王道”,即在“肉眼可见”的提升软件质量(如生产缺陷数的显著下降)之余,较大程度地缩短交付周期,较明显地提高人均产能,才最值得称道,简称为“提质增效降本”。是的,行之有效的DevOps实践,是可以实现这“不可能三角”的。

当我翻看这本书的书稿时,不禁想起多年前的一个阳光明媚的下午,包括本书几位作者在内的若干业界“老专家”一起热烈讨论的情景(我们对于突破“不可能三角”情有独钟)。那时候,我们希望能够在权威机构的指导下,汇聚业内在软件开发与交付方面的各种优秀实践,特别是互联网大厂的优秀实践,将这些实践传播到更多的企业及行业。考虑到各行各业的基础及目标要求不同,我们打算采用的方式是形成能力成熟度模型(信通院《研发运营一体化(DevOps)能力成熟度模型》,也被简称为DevOps标准),以此来调研和评估某个企业或某个团队做得怎么样,有哪些地方需要提升,并为此提供帮助和指导。

多年来,这套方法论在中华大地落地生根绽放,得到非常多的反馈,收获了很多新思路、新方法。我们也借此了解到各种实践在不同场景下落地所带来的实际效果。

本书的几位作者亲身参与其中,并且将他们多年来在软件交付领域的丰富经验汇聚于本书,试图回答这样两个问题:第一,持续集成、持续交付、敏捷、精益等优秀理念和相关实践,具体应该如何相互配合,综合运用,在软件交付领域落地;第二,应该怎样结合具体业务具体场景,选用合适的方法、制定合适的策略,以便高质效地完成软件交付。

与作者的上一本书《软件交付通识》相比,本书不仅大幅调整了章节结构和讲述方式,增加了各种图示,以求易读好懂,而且在内容上有较多更新迭代之处。例如,本书把软件交付对质量和效率的追求拆解为需求吞吐量、需求响应时长、问题出现量、问题修复时长四个方面,这构成了四个象限,每个象限都对应着若干改进思路和优秀实践;本书介绍了在软件交付过程中运用精益思想的若干可落地方法,并且介绍了突破Scrum的若干约束可能给软件交付过程带来的好处。

本书还开创性地把各类分支分为四个层级:特性级、集成级、生产级、版本序列级。把运行环境管理分为三个层次:如何把每个节点的本地运行环境管理好、如何让一个微服务在整体环境中运行起来、如何管理整套环境。在介绍软件交付相关的组织结构和人员职责时,本书提出了一个核心观点——组织结构设计的核心秘密是保持专注和减少依赖,并且据此从不同角度展开介绍。

正如只有自己嚼过甘蔗才知道哪节甘蔗好吃,好书之好,还需您自己细细品尝,方知其中美妙。希望这本书正是您在寻找的那一本。

萧田国 DAOPS基金会中国区董事 高效运维社区发起人


前言

想象一下,你在维护一个简单的个人网站。我们姑且把这称作编程,毕竟网站的实现包括一些使用JavaScript编写的脚本。你先登录服务器,修改了一处源代码,按下Ctrl+S组合键或其他快捷键,再使用浏览器访问你的网站,看到改动生效了。从软件开发的视角来看,你在完成了对源代码的修改之后,只需要“按个按钮”,瞬间就完成了软件发布。

这么看来,从修改完源代码到发布上线的过程是如此简单和快速,简直不值一提!呵呵,才不是这样的。在绝大多数严肃的软件开发场景中,从完成开发到发布上线需要的时间是以周为单位来计算的。

为什么这个过程会如此费时?因为大家分头完成的对源代码的修改需要先汇聚到一起,再一起发布;因为要把源代码编译打包,随后还要把安装包部署到服务器上并运行;因为我们要做各种测试以保证质量;因为要等到上线窗口才能发布;因为领导要审批……当我们分析某个团队的具体情况时,必然能看到由于各种各样的原因,最终会使得从修改完源代码到发布上线的这个过程需要一定的时间。

当我们说出这些原因的时候,内心充满自信和正义感:没错,就是因为这些原因,这很合理!然而,以本书作者过去十几年在软件集成、测试、发布方面的工作经验来看,特别是以近五年来向数十家企业的众多软件开发团队提供DevOps咨询所积累的经验来看,从修改完源代码到发布上线的这个过程所需要的时间往往可以基于团队现状显著地缩短,这个过程所需要的人力投入也可以显著地减少。换句话说,软件交付过程的效率还可以大幅度地提升。

如何能做到这一点呢?是的,我们确实需要把大家对源代码的修改汇聚到一起;我们确实需要通过构建和部署,把源代码形态的软件转化为运行中的软件;我们确实需要提升软件的质量直到可以交付给用户。这些都是我们必须完成的事情。然而如何高效率地完成这些事情却大有奥妙,其间往往有一处又一处可改进的空间。而改进的方法主要来自软件工程、敏捷、精益、持续集成、持续交付、DevOps、云原生、研发效能、平台工程等,它们都或多或少地涉及软件交付过程,告诉你软件交付过程该怎么做。

本书作者在向各企业、各开发团队提供咨询服务时,并不囿于上述某个“门派”:不会要求客户比照云原生十二因素逐项整改;不会因为“原教旨主义”的持续集成提倡把代码改动直接提交到集成分支,而将客户使用特性分支的方案视为旁门左道。同样地,本书的作者在书中也不会这样做。本书综合应用各家核心思想,讲解在今时今日具体该怎么做,才能取得最好的效果。我们本着务实的精神,不管白猫黑猫,只要能提高集成、测试、发布的效率,就是好猫。

市面上有不少好书,专精于特定的活动,如构建、单元测试,或者专精于特定的工具,如Git、Kubernetes。本书不是这样的书。对软件交付过程中各个具体活动、具体工具的详细讲解不是本书的重点,本书只会讲解其中的要点。否则,本书将厚达几千页,恐怕永远也无法交稿。本书关注的重点是各项活动应该在何时何处发生,应该如何统筹协调、合理安排,各个工具应该在何时何处使用以实现最大的效益。

本书分为6部分。第1部分带大家进入软件交付情境,将介绍软件交付过程的范围和内容,以及软件交付过程的追求目标。

第2部分是对软件交付总体过程的介绍和讨论。这部分将不仅讲解持续集成、持续交付这两个经典方法,讲解敏捷、精益等思想的应用,也将讲解在实践中涌现出的对经典方法和思想的调整、完善和发展。总之,我们将在这部分搭起软件交付总体过程的框架。

第3部分到第5部分将介绍软件交付过程中诸多具体活动的要点。第3部分将讲解版本控制、使用版本控制工具、分支策略、使用制品管理工具等内容。第4部分将讨论构建、构建环境、部署、运行环境、SQL变更、应用配置参数等内容。第5部分将首先介绍各类测试,然后介绍测试通用要点和测试通用策略,最后介绍缺陷修复。

第6部分补充了一些全局性内容,如组织结构与人员职责,这有利于高效交付的组织结构的设计。作为本书最后一部分,第6部分还总结了全书。

还有一些更“杂”的内容放在了附录中。例如,如果你对软件工程、敏捷、精益、DevOps之类的词汇感到陌生,那么可以先跳到附录A了解一下。

下面,让我们一起踏上软件交付之旅吧。


目录

第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.4 让微服务在整体运行环境中运行 174

22.5 管理整套环境 175

第23章 SQL变更 181

23.1 什么是SQL变更 181

23.2 自动执行SQL变更 182

23.3 确保SQL变更质量 182

23.4 程序与数据存储结构的版本匹配 183

23.5 管理SQL变更的特别之处 183

第24章 应用配置参数 187

24.1 什么是应用配置参数 187

24.2 应用配置参数的管理 188

24.3 如何设置应用配置参数 188

24.4 质量和安全 193

第5部分 程序质量的提升

第25章 静态测试 198

25.1 代码扫描 198

25.2 代码评审 200

25.3 软件成分分析 207

第26章 动态测试 209

26.1 单元测试 209

26.2 接口自动化测试 211

26.3 UI自动化测试 214

26.4 人工功能测试 216

第27章 重要但容易被忽略的测试 218

27.1 非功能测试 218

27.2 生产环境测试 221

第28章 测试通用要点 225

28.1 程序的输入:应对无尽的可能性 225

28.2 程序的输出:怎样写断言 229

28.3 测试数据准备 230

28.4 测试用例间的隔离性 231

28.5 如何更快地编写和维护测试脚本与数据 233

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.5 技术债:在必要时欠债 246

29.6 质量门禁:有原则有灵活性 248

29.7 Mock还是不Mock,这是个问题 250

29.8 质量反馈驱动测试改进 252

第30章 缺陷修复 255

30.1 管理缺陷 255

30.2 需求、测试、缺陷之间的关联关系 257

30.3 调试工具 259

30.4 测试环境的环境问题 261

第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.2 运用综合手段保证质量和安全 283

33.3 细粒度、低耦合、可复用的架构 286

33.4 自动化与自助化 289

33.5 加速各项活动 290

33.6 及时修复 292

33.7 完备记录,便捷查阅 293

33.8 标准化和一致性 296

33.9 协调完成完整功能 298

附录A 数十年来的探索 302

附录B 各类内容的版本控制方式 314


短评

    产品特色