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

推荐序 近年来关于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