软件交付通识-图书

推荐1
收藏4
浏览575

软件交付通识

董越 (作者)　

书　　号：978-7-121-42202-7
出版日期：2021-10-22
页　　数：260
开　　本：16(185*235)
出版状态：上市销售
维护人：张春雨

纸质版￥89.00

软件交付过程是指在编程序改代码之后，直到将软件发布给用户使用之前的一系列活动，如提交、集成、构建、部署、测试等。本书作为通识类图书，对软件交付过程的各个方面进行了全面综合的介绍。这包括三部分内容：第1部分，介绍在研究软件交付过程时常见的思路和思考框架；第2部分，梳理软件交付的总体过程；第3部分，考查软件交付过程中的各个具体活动。总的来说，本书提供了一种类似于对人进行体检的方法，对特定软件产品的交付过程进行全方位的调研，可以根据其所在的业务领域、当前采用的技术栈、使用的工具、流程和方法等实际情况，找出当前最突出、最值得改进的问题。

媲美大师经典彻底讲透软件交付||数字化转型、DevOps、持续集成、持续交付、持续部署、敏捷万用宝典

推荐序
近年来关于DevOps的讨论和实践，可谓是“风起云涌”，作为一项新型的理念和技术的综合体，其出现时间也就十来年，关于它的定义，难免仁者见仁，智者见智，现在我们摘取维基百科上的相关表述如下。考虑到中文版和英文版有些差异，因此一并列出。
DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. DevOps is complementary with Agile software development; several DevOps aspects came from the Agile methodology.
DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
两个语言版本的维基百科，有些不同之处。英文版提及了“持续交付”，中文版提及了“软件交付”，本书作者可能基于深度思考，也可能简单觉得“持续交付”被提及太多已然不酷（流水先生，即本书作者董越老师，不要生气哟），于是采纳“软件交付”作为本书书名的关键词。当然，不管称呼为“软件交付”还是“持续交付”，都可被认定是DevOps的核心工程实践。
DevOps的三个问题
DevOps火热得快，关于它有多个“未解之谜”，向来众说纷纭，这里暂且列举3个和你进行探讨。
首先，DevOps的两个CD究竟是什么关系？
有两个与DevOps相关的重要概念：持续交付（Continuous Delivery）和持续部署（Continuous Deployment），其简称都是CD。那么，这两者之间究竟是什么关系呢？
有人说，持续交付和持续部署是包含关系，前者包含后者。部署就是把程序包放到服务器上，无论把程序包放到测试服务器上还是生产服务器上，都被称为部署。所以，从字面上理解持续部署这个概念的话，持续交付理应包含持续部署，在之前包含持续集成，在之后包含持续发布。这听起来好像很有道理。
也有人说，持续交付和持续部署是递进关系，后者是前者的递进。这种关于持续交付和持续部署的分界定位的说法认为，持续部署所说的“部署”，是指生产环境部署，让生产环境的部署比持续交付时更频繁。追根溯源，其实这个说法才是当初提出“持续部署”这个概念的本意。Martin Fowler在他的博文中也写到，“持续部署意味着每个通过部署流水线的变更都被自动地部署到生产环境中，于是每天都会有若干次生产环境部署。”Jez Humble在《持续交付：发布可靠软件的系统方法》这本书中有更详细的介绍。维基百科也给出了类似的定义。本书作者也是按照这个定义来介绍的。
大家在阅读各种文章、各种图书时，看到“持续部署”这个词，心里可得有根弦儿——这里说的“持续部署”到底是什么含义。最好是文中就给出了它的定义。
类似的情况还有“特性团队”这个概念，特性团队中的“特性”其实和特性分支中的“特性”是完全不同的含义。本书中对特性团队、特性分支的概念也都做了明确的辨识和讲解。事实上，本书对DevOps、软件交付领域的众多重要概念都给出了明确的定义。
其次，DevOps只是昙花一现吗？
关于DevOps，其生命周期也是众说纷纭。“看衰者”说，DevOps也就昙花一现，可能速速消失在软件世界的“历史”长河中；“看好者”说，DevOps是软件工程领域的第三次革命，路还长着呢。那么，谁对谁错呢？
DevOps运动，强调从组织、流程规范特别是技术上把运维甚至安全（DevSecOps）等纳入进来，打通“最后一公里”，实现真正的端到端，从需求端到最终用户端。
然而，要想让一个团队做好这些，那就需要这个团队很强。但这很难，怎么办？可以让事情变得容易做，用不着那么专业的人来做。所以要开发各种工具，实现各种自动化，让工具足够好用，以至于一个人或者一个团队就可以做好集成发布过程，做好应用的运维、监控等各种操作。
具体而言，基于DevOps最佳实践，充分运用自动化技术形成了虚拟的、可被大量复制的软件生产及发布流水线。新功能开发完成后，不再需要请运维人员部署到测试环境，不再需要请测试人员做测试，开发人员可以一键触发自动化部署、自动化测试。
这样一来，通过DevOps的理念及技术指引，就真正实现了减少协作。
所以看来，DevOps的核心——持续交付，侧重于工程技术及落地实践，其打通了面向终端用户（价值）的“最后一公里”，看来不是昙花一现。
这跟本文作者前段时间的一个精彩发现不谋而合：高效协作的核心秘密是减少协作。
为什么这么说？因为人和人之间的合作是很累的，身体累，心更累。沟通需要不少时间，以理解上下文、进入状态（被打断后又得重新进入状态）。协调也需要不少时间，各有优先级，有各种争抢、各种排队、各种等待。若是赶上年假、时间冲突、新冠肺炎疫情等，那更麻烦。还有说不清道不明的人际关系及“软拒绝”。所以说，尽量一件事情能够从头到尾独立完成。
尽可能让一个人或者一个团队能够把一件事情负责到底。说到开发软件，就是从需求一直到上线。如果一个人做不好，那就一个团队来做，即所谓的全流程团队（或者全功能团队、跨职能团队、特性团队、stream-aligned team等），这个团队有着共同的目标，那就是已发布，而不是已开发、已测试或者已部署。这很类似于特种部队，其往往融合了海陆空的各种技能于一体，像一把尖刀，指哪打哪。
这不就是DevOps嘛！高效沟通的关键所在就是减少沟通，DevOps使得这些构想从理想变为现实。
最后，DevOps可以有标准吗？
正如维基百科所言，DevOps首先是一组最佳实践。DevOps融合了“务虚”和“务实”，既包括组织、流程、文档乃至文化，也包括自动化构建、自动化测试、自动化部署及发布等工程技术，法无定法，那么，DevOps会有标准呢？
DevOps就像水一样，水并无常态，有时液态，有时固态，有时气态，然而，喝水是否需要容器呢？小孩喝水用奶瓶，青年人喝水用塑料瓶，中年人喝水用保温杯。同理，DevOps作为最佳实践，其在各行业应用时，作为工程技术，还是有章可循的。例如，银行、证券和保险等行业，开展的业务是类似的，业务形态是相近的，部分业务系统甚至都外采于同一个供应商。
而且，这些都是从计算机软件生长出来的，在DevOps之前，也是多采用瀑布式开发模式，那么随着时代的车轮滚滚向前（云计算及云原生方兴未艾），DevOps必然也是大势所趋。
另外，我们所讨论的标准，并非平面标准（0或者1，通过或者不通过），而是能力成熟度模型，分为5级，主要以技术规范为主，颇具指导意义。
据说，现在各大国有银行、全国性股份制银行、城商行、头部券商及头部保险公司、运营商头部省公司等，都已纷纷前后“贯标”，相关项目的软件质量提升60%以上，需求发布速度提高300%以上。
软件交付的核心策略及金句
流水先生在互联网行业有很多年的DevOps实践，近两年因为机缘巧合，和众多金融名企如大中型银行及运营商等有过较长时间的深度接触，因此形成了十大核心策略。在关于十大核心策略及其在软件交付过程中如何应用的描述中，金句不断，在此采撷一二，以飨读者。
? 细粒度、低耦合，自己完成一件事情，不要总是动辄牵扯到别的人、别的事，这是软件交付的第一个策略。
? 在各个方面追求小批量：小批量的设计功能、交代开发任务，小批量的集成，小批量的测试，小批量的发布。于是，就有可能让整个流程持续地流动起来，而不是走走停停。
? 自动化工具要好用。其中比较重要的一点是，用户可以方便地自行配置使用，也就是自助化。
? 适当交叠有益，过分交叠有害。
? 每次代码改动提交，都应该是逻辑上完整地完成了一小块改动。
? 经典的持续集成方式是：开发人员可以随时向集成分支提交代码改动，而每次提交代码改动时都会触发一系列轻量级的自动化测试。
? 作为一个硬指标，通常应该是每次代码改动提交本身就既包括源代码的编写和改动，也包括相应单元测试脚本的编写和改动，并且这段单元测试脚本已经运行通过。
一个有趣的人和一本引人入胜的书
这是一本“老顽童”写的、看着不累的、“老少皆宜”的书。
“老顽童”加上双引号，主要不是因为流水先生“不顽皮”，而是因为不够老，毕竟流水先生正处于羽扇纶巾、大有可为的尚好年华。
流水先生治学严谨，相关著作侧重逻辑性，严格按照《金字塔原理》一书推荐的结构，层层递进，抽丝剥茧式向读者一一呈现；同时流水先生注重行文的诙谐幽默，尽量用通俗的语言娓娓道来，就像一位和蔼可亲的邻家大哥哥，“温柔地”注视着你，说，故事是这样的……
本书逻辑严谨，又不失轻松幽默。在提及本书的目的是“提供一种系统全面的方法”时，流水先生写道，“梳理出它在软件开发过程方面应该做哪些改进，以及轻重缓急，然后再从你的工具箱里拿出匹配的合适的工具，叮叮当当。”
“如果不是因为好玩儿，人生该多无趣啊！”流水先生是这样说的，也是这样身体力行的。
流水先生喜爱苏州评弹，这些年经常光顾同一个评弹小馆，去了多少次，我估计平江街的每一块铺路石单单根据受力情况，就知道。“哟，流水先生您又来了！”“对，去这儿。”“您里边请。”我甚至愿意相信，流水先生在编写本书时，脑海里就是以苏州评弹作为背景音乐的。
当年孔子向师襄学琴，师襄教了他一首琴曲，让他回去练习。他一弹就是十天。师襄觉得孔子已然弹得甚好，反复请孔子去学习其他新曲儿，但孔子总觉得不到位，即使他已经领会了琴曲的内涵。直到孔子说自己体会出作者是一个怎样的人了，他肤色黝黑，身材高大，目光明亮而深邃，似是一个统治四方诸侯的王者。师襄听后甚为惊叹，说：“这就是《文王操》啊！”
如果读者在赏阅本书的过程中，能咂摸出流水先生在写书时的音容相貌、神态表情，那就真的厉害了。前三位如实描绘出来的读者，请找流水先生或者我领取奖励一份。
——萧田国高效运维社区发起人、DAOPS基金会中国区执行董事

评审与致谢

本书经过了14位评审人认真细致的技术评审。没错，是认真细致、逐字逐句的技术评审，共收到788条评审意见，其中大部分被采纳。本书写作用了两个多月的时间，而根据评审意见修改又用了两个多月的时间。所以，这本书其实不是作者一个人完成的，而是作者和各位评审人共同完成的。
本书的评审人包括：企业中一线开发团队的负责人；企业中软件开发工具与流程改进的负责人；精益敏捷、持续交付、架构、测试、运维等方面的业界专家；DevOps标准（指中国信息通信研究院的研发运营一体化（DevOps）能力成熟度模型）的持续交付部分核心编写者。下面分别介绍（按拼音排序）。
陈展文，在招行服务18年，伴随着招行信息技术部从200多人发展到现在5000多人的规模，获得了PMP、CSM、CSPO、CSP、DOF、DOP、AWS CSAA认证。从推动配置管理工具Firefly起步，全程参与CMMI 三级体系的建立和认证，牵头招行CC、CQ、BuildForge、RTC和Git等全平台配置管理工具的落地实施。2015年开始牵头研究和推进DevOps持续交付实践落地，更好地支撑招行的精益化转型。2018—2019年牵头招行25个项目参与“DevOps标准持续交付部分3级评估”。2018年 DevOps国际峰会深圳站、2019年GOPS深圳站、2019年DevOps国际峰会北京站、2020年GOPS深圳站金牌讲师。担任QECon2020上海站与2021深圳站精益和敏捷专场出品人。

丁晓娇，百度DevOps方案架构师/资深敏捷教练，专注软件过程改进工作13年，4年研发管理经验；精通企业精益敏捷/DevOps转型方法和实践。具备互联网、金融、通信、电气等行业大中型企业DevOps或敏捷转型方案和落地经验。
段新，目前就职于中国移动广东公司，曾长期专注企业架构规划和转型实施。近年来痴迷于研究精益敏捷、DevOps在软件交付中的引入和推广，发现企业架构、精益敏捷、DevOps在软件质量与效能目标上的高度统一和互通，顿觉豁然开朗。

郭宏泽，15年IT行业工作经验，曾就职于易车网、电信云计算、跟谁学等公司。企业IT架构咨询师、IT培训师，曾为国内外各大公司做过专职咨询与培训。现任职于华图教育集团，担任技术总监。开发过日志分析系统、CDN流量计费结算系统，自动化IT管理平台、AdminSet开源运维管理平台作者。

华飞，就职于中原银行工程效能团队，主要负责企业内部DevOps平台建设。

井博巍，大家养老保险自营销售平台研发经理，乐于探索DevOps模式与敏捷思想，结合实际项目持续实践，提升项目效能并推广实践经验。深耕保险行业，关注IT项目在业务、技术、管理上的结合方案。曾任职于泰康养老，带领试点项目团队，实现DevOps模式转型。

景韵，DAOPS 基金会首席布道师，DevOps标准核心编写专家，DevOps Enterprise Coach，先后就职于用友、乐视，从事持续交付、DevOps 落地改进工作。

雷涛，Jenkins全球推广大使， DevOps标准工作组核心编写专家， DevOps Enterprise Coach，曾就职于百度、爱立信、摩托罗拉、诺基亚、新浪网等国内外知名企业，专注于互联网、金融、电信、汽车等行业的软件研发交付效能提升，包括企业级DevOps解决方案、持续交付、ASPICE/ISO 26262研发过程落地等领域。

李青，华泰证券股份有限公司效能专家，曾就职于摩托罗拉和中国移动。在15年的职业生涯中，从事过软件开发、项目管理、敏捷导入和产品设计等多种软件研发相关工作，跨越移动终端、运营商、互联网和游戏等多个领域，深入了解了不同角色、不同行业的研发过程。加入华泰证券以来，致力于推广精益理念，拥抱DevOps转型。作为项目经理和产品经理，主持打造了华泰证券的首个DevOps平台，并持续向研发过程一体化平台演进。

刘婷，郑州银行信息科技部基础平台科主管，主要负责持续交付平台等研发管理平台的建设；曾就职于百度质量部，负责运维软件及服务器硬件的测试开发工作。

牛晓玲，中国信息通信研究院云计算与大数据研究所治理与审计部副主任、DevOps系列标准及国际标准编写人。长期从事开发运维方面的相关研究工作，包括云服务的运维管理系统审查等相关工作。参与编写“云计算服务协议参考框架”“对象存储”“云数据库”“研发运营一体化（DevOps）能力成熟度模型”系列标准，以及“云计算运维智能化通用评估方法”等多项标准二十余项。参与多篇白皮书、调查报告等编制工作，包括《企业IT运维发展白皮书》《中国DevOps现状调查报告（2019年）》等。参与DevOps能力成熟度评估项目超过50个，具有丰富的标准编制及评估测试经验。

茹炳晟，业界知名实战派软件研发效能和软件质量领域专家，在国内外各大技术峰会上担任联席主席，国内外各大技术峰会的技术委员会成员及特定专题的出品人。现任腾讯技术工程事业群基础架构部首席研发效能架构师，腾讯研究院特约研究员。腾讯云最具价值专家TVP，阿里云最具价值专家MVP，华为云最具价值专家MVP，中国商业联合会互联网应用技术委员会智库专家，2020年度IT图书最具影响力作者，多本技术畅销书作者，Certified DevOps Enterprise Coach。

石雪峰，京东零售工程效能专家，专注于软件研发效能和数字化领域，Jenkins社区长期贡献者和全球大使，极客时间专栏《DevOps实战笔记》作者。

王晓翔，独立咨询师，去哪儿网工程效率部前高级总监，曾任奇安信内聘顾问，GOPS深圳大会金牌讲师，2019运维行业年度优秀技术专家，研发运营一体化（DevOps）能力成熟度标准咨询师。在软件配置管理、过程管理和工程效率方面有十几年的工作经验。曾在中国海关数据中心、索尼移动通信产品（中国）有限公司等多家公司工作。在去哪儿网供职七年间，逐步构建起持续集成、持续交付流水线，形成以应用为中心的全生命周期管理体系，并通过平台化不断为研发团队赋能，构建去哪儿网企业内部的DevOps生态圈，同时带领团队完成了从传统配置管理到工程效率团队的转型。

此外，畅销书《精益产品开发：原则、方法与实施》的作者何勉老师也对书中精益思想相关内容给予了具体的指导。博文视点张春雨老师的工作极为认真负责。高效运维社区、北京华佑科技有限公司在本书出版过程中亦给予了大力支持。在此对所有帮助本书写作和出版的朋友一并致谢。

第1部分　思维方式
第1章　本书要解决什么问题 2
1.1 提供一种系统全面的方法 2
1.2 分析软件交付过程 3
1.3 软件交付过程包括三类事情 4
1.4 软件交付不是按时间阶段或角色划分出来的 4
1.5 本书本质上是讲述软件交付这门学科 5
1.6 本书分成三个部分讲述 5
第2章　我们要追求什么 6
2.1 一切为了业务的成功 6
2.2 小步快跑 7
2.3 软件实现侧该追求什么目标 8
2.4 软件交付过程追求的目标 10
第3章　几十年来的探索 12
3.1 软件工程 12
3.1.1 软件危机 12
3.1.2 工程化 13
3.2 敏捷 14
3.2.1 敏捷的理念 14
3.2.2 敏捷的实践 15
3.3 精益 16
3.3.1 起源于制造业的精益思想 16
3.3.2 把精益应用于软件开发 17
3.4 持续集成 18
3.4.1 持续集成是什么 18
3.4.2 为什么要持续集成 19
3.4.3 如何做到持续集成 19
3.5 持续交付 20
3.5.1 包括所有质量验证工作 20
3.5.2 比较频繁地发布上线 21
3.5.3 持续部署 22
3.6 DevOps 22
3.6.1 DevOps的诞生 22
3.6.2 DevOps三步工作法 23
3.6.3 DevOps落地实践 23
3.7 技术方面的演进 24
3.7.1 软件架构 24
3.7.2 部署运行 24
3.8 它们之间是什么关系 25
第4章　做好软件交付的10个策略 27
4.1 细粒度、低耦合、可复用的架构 27
4.1.1 软件架构 27
4.1.2 测试脚本和测试数据的架构 28
4.1.3 组织架构 29
4.2 小批量持续流动的流程 30
4.2.1 大批量带来等待等问题 31
4.2.2 短周期、小颗粒度、减少在制品 31
4.2.3 小批量持续流动的交付过程 32
4.3 运用综合手段保证质量和安全 32
4.3.1 各种各样的测试 32
4.3.2 左移+右移 33
4.3.3 测试人员+开发人员 33
4.3.4 人工测试+自动化测试 33
4.3.5 综合运用 34
4.4 自动化与自助化 34
4.4.1 单项活动的自动化 34
4.4.2 流程的自动化 34
4.4.3 自助化 35
4.4.4 相关支持 35
4.5 加速各项活动 35
4.5.1 为什么要加速 35
4.5.2 加速的通用思路 36
4.6 及时修复 36
4.6.1 为什么要及时修复 37
4.6.2 如何做到及时修复 37
4.7 完备记录，充分展现 38
4.7.1 任务及其执行情况 38
4.7.2 版本和配置信息 39
4.7.3 关联关系 40
4.7.4 单一可信源 40
4.7.5 相关支持 41
4.8 标准化 41
4.8.1 规范可重复 41
4.8.2 方案收敛 41
4.8.3 环境一致性 42
4.9 协调完成完整功能 43
4.9.1 背景 43
4.9.2 开发全过程的协调 43
4.9.3 交付过程的协调 43
4.10 基于度量的持续改进 44
第5章　一个典型的软件交付过程 47
5.1 前传 47
5.2 代码改动累积并最终提交 48
5.3 特性改动累积并最终提交 48
5.4 集成并最终发布 49
第6章　各个细分领域 51
6.1 交付过程 51
6.2 源代码及其构建 52
6.3 部署运行 54
6.4 静态测试 54
6.5 动态测试 55
第7章　各个关注角度 58
7.1 执行时机 58
7.2 执行效果 60
7.3 执行效率 61
7.4 问题处理效率 62
7.5 避免引入问题 64
第2部分　总体过程
第8章　代码改动累积 68
8.1 导论 68
8.1.1 考查范围 68
8.1.2 关注重点 68
8.2 执行时机 68
8.2.1 包含改动的颗粒度：实时进行的测试 68
8.2.2 包含改动的颗粒度：随时进行的测试 69
8.3 执行效率 70
第9章　代码改动提交 71
9.1 导论 71
9.1.1 考查范围 71
9.1.2 关注重点 71
9.2 执行时机 72
9.2.1 包含改动的颗粒度：提交的颗粒度 72
9.2.2 包含改动的颗粒度：提交时进行的测试 72
9.3 执行效果 73
9.4 执行效率 73
9.4.1 执行效率度量：从发起提交到提交完成的时间 73
9.4.2 工具辅助记录和展现：代码改动提交说明 73
9.4.3 工具间集成：代码改动提交与工作项关联 74
第10章　特性改动累积 75
10.1 导论 75
10.1.1 特性的概念 75
10.1.2 特性隔离 76
10.1.3 考查范围 76
10.1.4 关注重点 76
10.2 执行时机 76
10.2.1 包含改动的颗粒度：代码改动提交触发的测试 76
10.2.2 包含改动的颗粒度：随时进行的测试 77
10.2.3 流程顺序和卡点：适当并行 78
10.2.4 管理并发：控制在研的特性数量 78
10.2.5 整体协调：完整的特性 79
10.3 执行效果 79
10.4 执行效率 81
10.4.1 自动执行：构建流水线 81
10.4.2 工具辅助记录和展现：流水线执行情况 81
10.4.3 方案收敛 82
10.5 问题处理效率 83
10.5.1 问题处理效率度量 83
10.5.2 适当通知 83
10.5.3 记录版本：流水线配置的修改历史 83
10.6 避免引入问题 84
第11章　特性改动提交 86
11.1 导论 86
11.1.1 考查范围 86
11.1.2 关注重点 86
11.2 执行时机 86
11.2.1 包含改动的颗粒度：特性的颗粒度 86
11.2.2 包含改动的颗粒度：当特性做不到既小又独立时 87
11.2.3 包含改动的颗粒度：特性提交时进行的测试 88
11.2.4 流程顺序和卡点：特性提交门禁 89
11.2.5 整体协调：完整的特性 89
11.3 执行效果 90
11.4 执行效率 90
11.4.1 执行效率度量：从发起提交到提交完成的时间 90
11.4.2 自动执行：合并请求 91
11.4.3 工具辅助记录和展现：特性内容说明 91
11.4.4 工具间集成：特性的代码改动与工作项之间的关联 92
11.5 问题处理效率 92
11.5.1 问题处理效率度量 92
11.5.2 适当通知 93
11.5.3 便捷回退：特性摘除 93
第12章　集成 94
12.1 导论 94
12.1.1 考查范围 94
12.1.2 关注重点 94
12.2 执行时机 94
12.2.1 包含改动的颗粒度：持续接收特性改动提交 94
12.2.2 包含改动的颗粒度：特性合入触发的测试 95
12.2.3 包含改动的颗粒度：针对新特性的测试 95
12.2.4 流程顺序和卡点：制品晋级 96
12.2.5 管理并发：适当交叠 97
12.2.6 管理并发：管理变体 98
12.3 执行效率 99
12.3.1 自动执行：部署流水线 99
12.3.2 工具间集成：版本的特性列表 100
12.3.3 工具间集成：特性状态信息 101
12.3.4 工具间集成：自动维护说明文档 102
12.3.5 自主完成：各项活动 102
12.3.6 自主完成：工具的配置 103
12.3.7 便捷配置 103
12.4 问题处理效率 103
12.4.1 问题处理效率度量：红灯修复时长 103
12.4.2 问题处理效率度量：缺陷修复时长 104
12.4.3 及时发现 104
12.4.4 适当通知 105
12.4.5 及时处理 105
12.4.6 快速定位 106
12.5 避免引入问题 106
第13章　发布 107
13.1 导论 107
13.1.1 考查范围 107
13.1.2 关注重点 107
13.2 执行时机 108
13.2.1 包含改动的颗粒度：发布的颗粒度 108
13.2.2 包含改动的颗粒度：发布前的测试 109
13.2.3 包含改动的颗粒度：生产环境的测试 109
13.2.4 减少等待：发布时间窗口 109
13.2.5 操作对象的颗粒度 110
13.2.6 整体协调：按一定顺序发布 111
13.2.7 整体协调：当在特性分支上完成全部测试时 112
13.2.8 整体协调：当每个微服务都有自己的迭代节奏时 113
13.2.9 整体协调：静态库典型情况之公共基础库 114
13.2.10 整体协调：静态库典型情况之整体应用的组成部分 115
13.2.11 整体协调：静态库典型情况之服务接口定义 116
13.3 执行效果 117
13.4 执行效率 117
13.4.1 执行效率度量 117
13.4.2 自主完成：精简发布审批流程 118
13.5 问题处理效率 118
13.5.1 问题处理效率度量：故障恢复与缺陷修复的时长 118
13.5.2 及时发现 118
13.5.3 适当通知 119
13.5.4 及时处理 119
13.5.5 快速定位 119
13.5.6 便捷回退：发布回滚 119
13.5.7 紧急改动的生效方式：紧急发布 120
第3部分　具体活动
第14章　源代码版本控制 122
14.1 导论 122
14.1.1 考查范围 122
14.1.2 关注重点 122
14.2 执行时机 123
14.2.1 管理并发：晚分叉模式支持交叠 123
14.2.2 管理并发：早分叉模式支持交叠 124
14.2.3 管理并发：用主干代表最新已发布版本 125
14.2.4 管理并发：特性分支的管理 126
14.2.5 操作对象的颗粒度：代码库的尺寸 127
14.3 执行效果 127
14.4 执行效率 128
14.4.1 执行效率度量 128
14.4.2 快速执行：分布式版本控制工具 128
14.4.3 快速执行：便捷的页面操作 129
14.4.4 规范可重复：管理众多代码库 129
14.4.5 规范可重复：明确代码库内的目录结构和内容 129
14.4.6 规范可重复：规范版本号 130
14.4.7 规范可重复：标识源代码版本 131
14.5 问题处理效率 132
14.5.1 便捷回退：特性摘除 132
14.5.2 便捷回退：发布回滚 132
14.5.3 紧急改动的生效方式：已提交特性的修改 133
14.5.4 紧急改动的生效方式：紧急发布 133
14.6 避免引入问题 134
第15章　构建 135
15.1 导论 135
15.1.1 构建的概念 135
15.1.2 考查范围 136
15.1.3 关注重点 136
15.2 执行时机 136
15.3 执行效率 137
15.3.1 工具辅助记录和展现：构建遇到的问题 137
15.3.2 快速执行：从全局视角提速构建 138
15.3.3 规范可重复：构建的可重复性 140
第16章　构建环境管理 142
16.1 导论 142
16.1.1 考查范围 142
16.1.2 关注重点 142
16.2 执行效率 142
16.2.1 规范可重复：构建环境标准化 142
16.2.2 资源复用：构建环境资源池化 143
16.2.3 快速执行：保障随时有构建资源可分配 144
16.2.4 快速执行：保障构建所需的缓存 145
第17章　制品管理 146
17.1 导论 146
17.1.1 制品的概念 146
17.1.2 考查范围 147
17.1.3 关注重点 147
17.2 执行时机 147
17.3 执行效果 148
17.3.1 覆盖范围：外来制品 148
17.3.2 覆盖范围：工具和基础软件 148
17.4 执行效率 149
17.4.1 执行效率度量 149
17.4.2 工具辅助记录和展现：制品的属性信息 149
17.4.3 工具间集成：源代码、构建、制品之间的关联 150
17.4.4 快速执行：快速存取 150
17.4.5 资源复用：不重复存储 151
17.4.6 规范可重复：管理众多制品 151
17.4.7 规范可重复：标识制品版本 152
17.4.8 规范可重复：标识静态库版本 152
17.4.9 规范可重复：制品清理策略 153
17.5 问题处理效率 154
17.6 避免引入问题 154
第18章　部署 155
18.1 导论 155
18.1.1 部署单元的概念 155
18.1.2 考查范围 156
18.1.3 关注重点 156
18.2 执行效果 156
18.3 执行效率 157
18.3.1 自动执行：完全自动化 157
18.3.2 工具间集成：以部署单元为核心对象 157
18.3.3 自主完成 158
18.3.4 便捷配置：避免重复配置 159
18.3.5 快速执行 159
18.4 问题处理效率 160
18.4.1 及时发现 160
18.4.2 便捷回退 160
18.5 避免引入问题 160
18.5.1 业务连续性：生产环境的部署策略 160
18.5.2 业务连续性：测试环境的部署策略 161
18.5.3 业务连续性：客户端的部署策略 162
第19章　运行环境管理 163
19.1 导论 163
19.1.1 运行环境的概念 163
19.1.2 考查范围 163
19.1.3 关注重点 164
19.2 执行效果 164
19.2.1 执行效果度量：保证足量供应 164
19.2.2 执行方法：声明式 164
19.2.3 环境一致性：本机运行环境 165
19.2.4 环境一致性：整体运行环境 166
19.3 执行效率 166
19.3.1 执行效率度量 166
19.3.2 自动执行 167
19.3.3 工具间集成：制品、部署、环境之间的关联 167
19.3.4 自主完成 167
19.3.5 资源复用：环境实例的分配与回收 168
19.3.6 资源复用：虚拟独占方式 168
19.3.7 资源复用：处于整体环境中的个人开发环境 168
19.3.8 方案收敛 169
19.4 避免引入问题 169
第20章　配置参数管理 170
20.1 导论 170
20.1.1 系统配置参数的概念 170
20.1.2 业务配置参数的概念 170
20.1.3 考查范围 171
20.1.4 关注重点 171
20.2 执行时机 171
20.2.1 流程顺序和卡点：设置方式 171
20.2.2 流程顺序和卡点：选择设置方式 172
20.2.3 流程顺序与卡点：确保质量 173
20.2.4 整体协调：程序与配置参数的匹配 173
20.2.5 整体协调：键值分离 173
20.3 执行效率 174
20.3.1 自动执行 174
20.3.2 自主完成 175
20.3.3 便捷配置：减少人工设置内容 175
20.4 问题处理效率 175
20.5 避免引入问题 176
第21章　数据存储结构管理 177
21.1 导论 177
21.1.1 数据存储结构管理的概念 177
21.1.2 考查范围 177
21.1.3 关注重点 178
21.2 执行时机 178
21.3 执行效果 178
21.3.1 执行方法：应对挑战的常见方法 178
21.3.2 执行方法：声明式 179
21.3.3 环境一致性 180
21.4 执行效率 180
21.4.1 自动执行 180
21.4.2 自主完成 180
21.5 问题处理效率 181
21.6 避免引入问题 181
第22章　代码评审 182
22.1 导论 182
22.1.1 代码评审的概念 182
22.1.2 关注重点 182
22.2 执行时机 183
22.2.1 包含改动的颗粒度：通常以特性为单位 183
22.2.2 包含改动的颗粒度：结对编程 183
22.2.3 流程顺序和卡点：事前评审和事后评审 183
22.3 执行效果 185
22.3.1 执行效果度量 185
22.3.2 覆盖范围：根据场景选择合适的测试力度 185
22.3.3 覆盖范围：不仅包括源代码的改动 186
22.3.4 执行方法：代码评审的形式 187
22.3.5 执行方法：检查清单 187
22.3.6 人员能力：做代码评审需要专门的技能 188
22.4 执行效率 188
22.4.1 执行效率度量 188
22.4.2 工具辅助记录和展现：记录评审发现的问题 188
22.4.3 工具间集成：IDE能力 189
第23章　代码扫描 190
23.1 导论 190
23.1.1 代码扫描的概念 190
23.1.2 关注重点 191
23.2 执行时机 191
23.2.1 流程顺序和卡点：只卡增量 191
23.2.2 流程顺序和卡点：技术债可以通融 191
23.3 执行效率 192
23.3.1 快速执行 192
23.3.2 规范可重复：定制规则 192
23.4 问题处理效率 193
第24章　制品分析 194
第25章　单元测试 196
25.1 导论 196
25.1.1 单元测试的概念 196
25.1.2 自动化测试用例和测试脚本的概念 196
25.1.3 关注重点 197
25.2 执行时机 197
25.2.1 包含改动的颗粒度 197
25.2.2 流程顺序和卡点：尝试性工作推迟测试 197
25.2.3 流程顺序和卡点：测试驱动开发 198
25.3 执行效果 198
25.3.1 覆盖范围：代码覆盖率 198
25.3.2 人员能力：测试设计是一门学问 199
25.4 执行效率 200
25.4.1 快速测试准备：测试脚本的自动化生成 200
25.4.2 快速执行：只测试增量部分 200
25.5 问题处理效率 201
25.5.1 快速定位：调试器 201
25.5.2 记录版本 201
第26章　自动化接口测试 202
26.1 导论 202
26.1.1 自动化接口测试的概念 202
26.1.2 关注重点 202
26.2 执行时机 202
26.2.1 包含改动的颗粒度 202
26.2.2 流程顺序和卡点：先做增量测试 203
26.2.3 流程顺序和卡点：测试驱动开发及其变体 203
26.3 执行效果 203
26.3.1 覆盖范围：较高的覆盖率 203
26.3.2 覆盖范围：仅在必要时Mock 204
26.3.3 覆盖范围：单次调用和完整场景 205
26.4 执行效率 205
26.4.1 工具间集成：特性、测试脚本、测试执行、缺陷之间的关联 205
26.4.2 自主完成：鼓励开发人员编写测试脚本 206
26.4.3 快速测试准备：测试脚本与测试数据分离 206
26.4.4 快速测试准备：测试脚本的分层与复用 207
26.4.5 快速测试准备：测试数据的分层与复用 208
26.4.6 快速测试准备：事先创建测试数据的方法 208
26.5 问题处理效率 208
26.5.1 快速定位：问题自动分类 208
26.5.2 快速定位：接口调试工具 208
26.5.3 记录版本：与源代码同步 209
26.6 避免引入问题 209
26.6.1 引入问题度量：减少误报 209
26.6.2 隔离性：不受其他测试干扰 210
26.6.3 隔离性：管理测试用例之间的依赖 210
26.6.4 工具可靠性：测试数据备份 210
第27章　人工UI测试 211
27.1 导论 211
27.1.1 UI测试的概念 211
27.1.2 关注重点 211
27.2 执行时机 212
27.2.1 包含改动的颗粒度 212
27.2.2 流程顺序和卡点 212
27.3 执行效果 212
27.4 执行效率 213
27.4.1 工具间集成：特性、测试执行、缺陷之间的关联 213
27.4.2 自主完成：开发人员自测 213
27.4.3 快速测试准备：探索性测试 214
27.5 问题处理效率 214
第28章　自动化UI测试 215
28.1 导论 215
28.2 执行时机 215
28.3 执行效果 216
28.4 执行效率 216
28.5 问题处理效率 217
第29章　非功能测试 218
29.1 导论 218
29.1.1 考查范围 218
29.1.2 关注重点 218
29.2 执行时机 218
29.3 执行效果 219
29.3.1 覆盖范围：性能与容量 219
29.3.2 覆盖范围：安全性 220
29.3.3 覆盖范围：兼容性 220
29.3.4 覆盖范围：易用性 220
29.4 执行效率 221
29.4.1 自动执行 221
29.4.2 快速测试准备：事先创建测试数据的方法 221
第30章　生产环境测试 222
30.1 导论 222
30.1.1 考查范围 222
30.1.2 关注重点 222
30.2 执行效果 222
30.2.1 覆盖范围：功能测试方面 222
30.2.2 覆盖范围：非功能测试方面 223
30.2.3 执行方法：小范围试用 223
后记 225