《持续交付》读书笔记

读乔梁先生《持续交付2.0》摘要，仅供学习交流

一、持续交付2.0

1.1 软件工程发展

1、瀑布软件开发

2、敏捷软件开发

提倡面对面沟通，拥抱变化，提倡通过迭代和增量开发今早交付有价值的软件，软件开发实际是一个不断迭代学习的阶段。

瀑布只有在项目交付后期才可以看到软件的实际运行。
敏捷开发采用迭代模型，但是软件发布之间的间隔较长。需求变更&研发效率是主要矛盾，部署发布&运维矛盾较小。

3、DevOps发展

DevOps目前没有统一的定义，正如每个人理解敏捷是不一样的。目标是缩短开发周期，提高部署频率和刚可靠的发布，与业务目标一致。

4、持续交付1.0

部署流水线：

每个隔间阶段都应该交付可工作的软件，中间产物的生成不应该是独立的阶段。
同一个制品向不同类型的环境部署，且运行时的配置分开管理。（Apollo）
自动化测试和部署，根据测试的目的，分为几个独立的质量关卡。（流水线测试卡点）
部署生产线设计应随着应用程序的发展而不断演进。

5、持续交付与持续部署。部署是技术领域的，交付是业务决策。交付可理解为上线、发布，部署可能有多次，而在业务需要时，才会交付。

1.2 持续交付2.0

1、精益思想

《精益创业》线产生最小化的可行性产品，而非玩么牛的产品，在经过快速迭代与持续修正，资源耗尽前实现市场需求。

精益创业是“开发–测量–认知”的验证学习过程。
按照价值流来组织全部生产活动是价值在生产活动之间流动，需求拉动产品的生产，识别生产过程中不经意间的浪费产生。
业务生产活动分为增加价值的活动和不增加价值的活动，后者归为“浪费”活动中，浪费活动分为必要的增值活动和纯粹的浪费。{有价值，无价值[必要浪费，不必要浪费]}。EG：流水线上的装配工作是增值活动，质量检查是非增值活动，因材料不足而生产等待和质量缺陷的返工都是不必要的浪费。

2、双环模型【★】

产品研发管理思维框架，是产品与研发的快速闭环，以“精益思想”为指导，全面贯彻“识别和消除一切浪费”的理念。有可持续方式、高质量、低成本、无风险的快速交付客户价值。
”8“字环，第一个为**“探索环”，目标为识别和定义业务问题，制定最小可行解决方案；第二个为“验证环”**，目标为一最快速度交付最小可行环，可靠的收集真实反馈，并分析和验证业务问题的解决效果。，以确定下一步的行动。

探索环：
1. 提问，即定义问题。通过有针对性行的提问，找出用户具体需求，并找出具体需求后的原因，即要解决的根本问题。
2. 锚定，即定义结果目标指示器。经过分析，去除干扰信息，得到适当的衡量指标，并表述现在的状况和行动预期的结果。
3. 共创，制定目标后，团队设法验证或者达成目标，而探索多种可行性解决方案。
4. 精炼，即对所有的可行方案进行选择，找到最小可行性解决方案（单个或者多个混合）。
验证环：
1. 构建，最小可行性解决方案转化为符合质量需求的软件包。
2. 运行，部署到生产环境或者交到用户手中，并使之为用户提供服务。
3. 检测，生产系统的系统和数据监控，保证运行，并将业务数据以适当的形式展示。
4. 决策，数据分析与目标对比，决策下一步方向。
3、四个核心原则：
1. 坚持少做。想做的事情永远超出自己的交付能力，即使在微软，也只有1/3的新特性成功改进了关键指标。
2. 持续分解问题。
3. 坚持快速反馈。快速反馈工作的结果。
4. 持续改进并衡量。

补充：VUCA模型

volatility （易变性）
uncertainty （不确定性）
complexity （复杂性）
ambiguity（模糊性）
VUCA这个术语源于军事用语，在20世纪90年代开始被普遍使用，用来描述冷战结束后的越发不稳定的、不确定的、复杂、模棱两可和多边的世界。随后， VUCA被战略性商业领袖们用来描述已成为“新常态”的、混乱的和快速变化的商业环境。

二、价值探索环

2.1 探索环的意义

1、探索环的目标与价值假设

用户假设：潜在用户的需求假设
问题假设：问题点痛点的需求假设
解决方案假设：提供的方案可以解决这些痛点或问题点，且比其他方案高效

EG：持续交付工具GoDC，设计200多个功能特性，一半都废弃掉，说明假设的不成立。该产品实际一直秉承“持续交付2.0”，调整功能策略，实现成功。

2.2 探索环的四个关键

1、提问

不断提问，澄清客户需求背后真正要实现的目标。

EG：举办DevOps的沙龙，客户要咖啡。问了一堆要什么口味的咖啡、多热的咖啡、什么时间、中杯大杯。

其实问的都是“做什么”和“怎么做”，而没有去问及原因。客户真正的诉求是担心困意而错过听讲。此时，我们的解决方案有多种，比如录制视频，即使参与者中途离场，也可以回顾内容。

2、锚定

避免模糊不清的目标，这样会影响团队的交流。清晰的描述目标让我们知道自己当前的位置，目标是：清晰、具体、可衡量的、有时间限定。若没有时间限定，则将会成为一个愿景，无法直接知道企业日常生产管理的活动。

清晰、具体、可衡量、有时间限制。

EG：某App用户量当前为20万，年底愿景为200万。

所以我们可以根据新闻信息流服务（Feed流），我们期望用户喜欢该App，那么可以推断：
1. 用户会阅读更多的内容，花费更长的时间
2. 用户会将该产品推荐给朋友，而朋友也会喜欢并成为该产品的用户。

根据分析可以得出三个衡量指标：推荐朋友数、单位时间内的用户数、单个用户的平均使用时长。制定指标后，各个团队根据自身职责制定目标如：提高API的请求响应速度、后台稳定性等等。
目标选择应该遵循：
1. 识别价值目标而非虚荣目标。
2. 指标应该是可衡量且可获取，易于客观对比。

3、共创

解决方案基于假定条件或者猜想，提供两种分析方法：

量化式影响地图（目标–角色–影响–方案–量化、Why-Who-How-What）。

EG：以20万到200万为例。涉及到的角色有App使用者、推广渠道、客服团队、产品研发和运营、内容提供商及更多角色。

以推广渠道商为例
- 角色：列出设计的人或者角色
- 方案：购买展位、搜索优化、规范更新
- 量化：App的下载指标
用户陆行地图（可视化的方式，讲用户与产品或服务之间的活动按照业务流进行展示）

四个部分：
- 用户接触点
- 接触阶段
- 用户痛点
- 用户情绪
制作步骤：
- 定义用户
- 定义任务或阶段
- 用户与服务接触点的互动行为
- 用户的动机
- 用户心理

共创的两个陷阱、两个极端：

分析瘫痪（过度分析，无法决策）、
直觉决策（匆忙判断，直觉反应）

4、精炼

筛选最小可行性方案。精炼的目标并不是为了删除在共创阶段得出的解决方案，而是将它们按优先级排列，并让团队将解决方案进一步分解，顺序选出共同认可的最重要改进项，并确保它能够尽早被验证。

2.3 工作原则

1、分解快速验试错

与“一次到位式”的解决方式不同。采用低成本的快速验证，多次尝试，多种方法，多种成功方式。

2、一次只验证一点

验证方案只是手段，非目标。

3、允许失败

2.4、共创和精炼常用方法

1、装饰窗方法

EG：提现的功能，产品为评估到实现周期较长，则可以线用一个虚假的按钮，如用户点击“提现”时，提示“功能未实现，请预留手机信息，实现后第一时间提心您”，从而收集用户点击意愿，快速收集用户反馈，决定是否做该功能。

2、最小可行特性法

EG：还是提现的功能，可以提示“功能开通成功”，后台收集用户信息，通过人工财务方式，实现该功能，并不涉及到系统的开发。用来短时间内收集用户意愿，验证用户是否喜欢该功能。

3、特区法

制定用户范围内进行试验，验证某个功能是否有效，不会影响特区意外的用户体验。一般用于资源有限、成本敏感的场景。

EG：还是提现的功能，按照装饰窗方法，若120个用户提交手机信息，功能实现后，可以根据120用户手机发送短信，包含提现的连接，查看用户点击该链接完成提现的人数（如：33个商户提现成功，7个商户提现1次，1个商户提现8次）。

4、定向探索法

是指某种特定行为的特定用户群体，依据改用户的具体行为模式，设计调查提纲，针对性探索其背后的动机。根据特区法的不同商户提现结果，分别设计调查问卷，理解用户行为。

5、稻草人法

与装饰窗方法的区别是不开发任何真实功能，假装该功能已经实现。采用人工或其他方式，模拟实现，获得用户反馈。

6、最小可行产品法

通常在产品0-1的过程中使用。如Zappos最早就是开发一个UI界面，然后用户下单后，手工发货。

三、快速验证环

3.1 验证环的目标

借助各种方法和工具，让质量可靠的解决方案以最快的速度达到客户手中，收集分析真实的反馈。

3.2 验证环的四个关键

1、构建：讲自然语言描述转换为计算机可以执行的软件。

“时间盒”管理法。涉及交付物、交付质量、截止时间，了解项目状态，风险并解决。
任务分解。持续交付2.0核心工作原则，包含需求拆分和开发任务拆分。
持续验证。每当完成意一项开发任务或者需求，立即对交付质量进行验证，而非多项交付一起验证。持续验证会耗费较高成本，可以采用“持续集成”或者“自动化测试”方式，降低回归成本。

2、运行：将软件包部署生产环境，并对外提供服务。

如何无感的升级版本是重要课题，主要矛盾在开发和运维之间。

3、监控：收集数据源并统计展示，及时发现生产问题和业务指标异常的数据。

4、决策：收集真实的业务数据反馈结果之后，根据探索环中确定的相应指标进行分析对比，验证是否符合最初预期。

3.3 工作原则

包含：质量内建、消除等待、尽量并行、检测一切。

1、质量内建。从生产过程的第一个环节开始，就注重产出物的质量，并在每个环节开展质量保证。与后期大规模检查概念完全相反。

2、消除等待。精益思想中关于“浪费”有定义，“等待”的本质就是非必要浪费。正确做法是扩大“瓶颈”的处理能力，本质解决为需求颗粒均匀化，构建各环节工作量相近的需求。同时进行任务的自动化建设。

3、重复任务自动化。如测试环境搭建、回归测试、应用发布和部署，都可以通过优化流程和自动化措施降低事物性成本和人为造成的失误。

4、检测一切。检测收集数据，便于确认生产环境软件正常运行（应用健康检测），也便于收集有效业务数据，验证探索环的假设（业务健康假设）。

四、持续交付2.0的组织文化

4.1 安全、信任与持续改善（文化核心）

1、失败是安全的：无法保证决策的绝对正确性，如果无法让成员感受到“失败是安全的”，则会避免犯错，逃避责任，缺少合作。

2、相互信任：信任是相互的，如果缺少“相互信任”，会出现“产品认为开发人员不给力”和“开发人员认为产品不靠谱”的潜在暗示。

3、持续改善。特点为：人人参与、时时改善。不指是某个角色的责任，而是所有人的责任；时时改善应该是日常工作，而非事故发生后的分析改进。

4.2 文化塑造四步法则【imp】

定义我们要做的事
定义我们期望的做事方式或方法
提供相应的培训，使员工具备完成其工作的能力
设计一些必要的机制和措施来强化我们鼓励的行为

EG1：丰田Andon的信灯，员工赋权

EG2：谷歌建立的工程师质量文化
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-v9WzJq9J-1632932686623)(3CF0457DA33A461F894B5D82FC5C2A08)]

4.3 行动原则

价值导向

任务很多，要思考完成这些任务的目的，思考任务与目标之间的关系。思考手头在做的事情是否仍具有价值。

快速验证

快速实施，得到真实反馈，从而做出抉择。

持续学习

无法保证每个决策是正确的，每一次反馈都应该作为一次学习的解决，结合学习到的新知识，总结成功经验或者失败教训。

定期回顾
复盘机制(因果、为什么)

以上两种学习方式都要运用系统思考能力：季度制定的目标P0，做的慢，导致战线过长，开发、测试多线程运转，更加耗时。（规划不清楚、线上问题、需求插入、需求变更、优先级不明确的并行，新工作量发现）导致看起来项目时间长，总以为是人力资源问题，或者认为是需求太多。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tiGYrYly-1632932686625)(30D783C913F447608A5526CFE621C8CF)]
不论从人员能力、组织规范、软件架构、组织流程制度、组织激励方面、非自身可控的外部事件，其实核心问题都是“规划不清晰”。

度量原则

度量的四类指标：

引领指标和滞后指标

引领指标对达成预定目标有重要作用的指标，具有可预见性、团队成员可以影响这些指标。
滞后性指标是指为了达成最终要目标的的跟踪性指标。指标有相对性，企业的终极后验性指标是客户价值，相对于这个滞后性指标，其他指标都是引领性指标。

可观测性指标与可行动性指标

可观测性指标是指可以被客观检监测到，但是无法通过直接行动来改变的指标。

可行动指标是指在能力可触达范围内，通过团队努力可以设法改变的指标。

如：千行代码缺陷率就是一种可观测行指标。只能通过更全面的质量保障活动来影响这一指标；代码规范符合度、重复代码率等即是可观测指标，也是可行动指标，因为可以通过修改代码影响这些指标。

如：“ DevOps状态告2017”指出，衡量IT高绩效组织的4个度量项分别是发布频率、发布周期、MTBF/MTTR 、吞吐量。则测试效率、部署效率、编译速度等都是引领性指标。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8QiaDbKN-1632932686626)(B9F7B8F189F447C9B61B994B6426A266)]

度量的目标的是改善：如单元测试完全可以通过写没有断言的方式来达成，但是这种测试代码覆盖率毫无意义。如果度量毫无目的，则改用其他度量项，要么做好管理工作。

改善套路

明确方向
掌握当前状态
义下一目标状态
迭代改进

5.持续交付软件系统架构

巨石应用到微服务，为什么做微服务，2000年亚马逊电商平台若部署时，需要将整个站作为一个整体统一部署。各个系统之间增加沟通与减少团队沟通，选择后者，从巨石架构转变为面向服务的架构（SOA）

5.1“大系统小做”原则

1、持续交付架构要求

为测试而设计：支持快速验证，减少测试准备工作
为部署而设计：快速部署，无需停机
为监控而设计：支持监控
为扩展而设计：系统与团队成员的扩展。
为失效而设计：部署失败的优雅快速处理。

2、系统拆分原则

大系统由很多组件（Component）和服务（Service）组成，颗粒度大于class，通常为jar/war/ dll/ gem等。有清晰的业务职责，可以独立被修改甚至代替；“高内聚、低耦合”，系统易于维护，知道尽量少的信息；易于构建和测试；使团队之间沟通与协作更流畅。

5.2 常见的架构模式

1、微核架构（客户端）

微核架构（ microcore architecture ）又称为插件架构（ plugin architecture ），指的是软件的核心框架相对较小，而其主要业务功能和业务逻辑都通过插件实现，
常用于需要向用户分发的客户端软件。

优点

良好功能延伸性
易发布
易测试
可定制性高
可以渐进式的开发

缺点

扩展性差：内核通常是一个独立单元，不容易做成分布式
开发难度较高：设计插件与内核的通信，以及内部的插件等级机制等
高度依赖框架：框架接口升级时，会影响所有插件

2、微服务架构（大型后台服务）

划分为小的服务，服务之间直相协调、互相配合，每个服务运行在其独立的进程中，服务与服务问采用轻量级的通信机制互相沟通（通常是基于HTTP协议的RESTful API)。每个服务都围绕着具体业务进行构建，井且能够被独立地部署。

优点

展性好一一各个服务之间低耦合。可以对其中的个别服务单独扩容
易部署一一每个服务都是可部署单元。
易开发一一每个组件都可以进行单独开发，单独部署，不间断地升级。
易于单独测试如果修改只涉及单一服务，那么只测试该服务即可。

缺点

由于强调互相独立和低辑合，服务可能会被拆分得很细。这导致系统依赖大量的微服务，变得很凌乱和笨重，络通信消耗也会比较大。
一次外部请求会设计内部多个服务之间的通信，使得问题的调试与诊断比较困难，需要更强大的工具支持。
为原子操作带来困难，例如需要事务类操作的场景。
跨服务的组合业务场景的测试比较困难，通常需要同时部署和启动多个微服务。
公共类库的升级管理比较难。

3、巨石架构（中小型项目）
一坨，单一结构体组成的软件应用，完整的自我系统，如一个jar包，一个Node.js。

优点

利于开发和调试
部署操作简单
容易扩展

劣势

学习成本高
难以与新技术共同使用
只能将整个应用作为一个整体扩展
持续部署困难

5.3 架构改造实施模式

1、拆迁者模式（重构）

重新写设计与实现，就是一次性重写所有代码。

2、绞杀者模式（逐渐替代）

就是不改变或少改变原有遗留系统，通过增加新的服务来不断替代遗留系统的功能。

3、修缮者模式（内部部分重构）

原有遗留系统逐步改造。

6.业务需求协作管理

产品生命周期概念阶段、孵化阶段、验证阶段、运营阶段和业务退市阶段。

6.1 产品版本周期

1、包含准备期和交付期，准备期目标是让参与的所有决赛对期望业务达成最小可行解决方案的共识。交付期目标为通过快速迭代，验证解决业务问题。

2、准备期：达成业务理解和目标共识。

目标阐述与理解：
业务领域角色与流程识别，及解决方案的探索
重大风险识别与验证：
精炼并达成最小可行方案共识：
评估与计划：

3、交付期：
交付期也由多个选代组成，各迭代周期应尽量保持一致。每个迭代中可能包含多个持续交付“ 8”字环。

6.2 需求拆分的利与弊

需求分析、概要设计、详细设计、编码、集成测试各个阶段再分解，分为不同的模块。传统方式在联调和测试阶段的缺陷较多，延期风险较高。持续交付的拆分原则：坚持以业务视角对需求进行拆分。
1、需求拆分的收益

建立共识，协调工作。需求提前拆分，各个方面达成共识。
小批量交付，加速价值流动。交付一部分红丝线的内容，用户更早使用，更早创建价值。
低成本拥抱变化
多次集成，及时反馈质量
鼓舞团队士气

2、需求拆分的成本

需求拆分时的显式成本

产品经理拆分需求，由于技术背景不充足，需要其他角色卷入，导致前期沟通成本增加。

分批开发、测试和部署的迭代成本

验证成本增加，每次都要回归之前的迭代，验证次数增加。

6.3 需求拆分方法

即：如何按照业务到导向拆分，并且拆的足够小/p>

满足眼前需求，没有进一步考虑
低质量代码

持续交付中的另一种“技术债”，影响软件交付速度和业务速度，如手工准备测试环境，手工回归吃啥，手工部署与发布（可以用自动化技术解决的）

3、参与需求拆分的角色

开发人员和测试人员参与需求拆分，更容易掌握产品需求上下文。更多的角色应该参与到用户故事编写，更充分了解。

4、不平等的INVEST原则【IMPORTENT】

INVEST
SMART
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-f1XpoxKj-1632932686628)(B01CC3F736D44F68A044A21A7C3D8B91)]

5、五大拆分法

拆分用于掌握用户故事方法

路径拆分法。根据用户使用场景的不同路径进行拆分。

EG：如支付可以采用微信支付和银行卡支付，银行卡支付可以包含招商、工行等，看用户故事需要覆盖主干。
按接触点拆分。接触点即用户与系统之间的交互通道。

EG：如移动应用端和PC浏览器是不同的接触点，根据浏览器则可以分为用户通过IE内核/非IE内核查看。
按数据类型或格式拆分。

EG：如导入文件的格式可以分为，用户通过CSV/EXCEL方式上传文件。
按规则拆分。

业务规则或者技术规则拆分。

EG：如海上航运，可以按照时间最短、路程最近等方式。
按探索路径拆分。

对于陌生事物或者不确定的方案，通过拆分等方式模拟用户故事。

6、七大组成部分

用户故事可以由七个部分组成：编、名称、描述、技术备忘、前提假设、依赖关系、验收条件。

6.4 需求分析与管理工具集

1、用户故事地图

X轴为行为路径，Y轴为不同级别的目标。每个行为有不同的步骤，在不同的目标中体现。

2、用户故事树

树状图描述，在购书站上的用户有购买者和理货者，购买者可以查找书籍、支付等，查找书籍可以通过按照类型、书名等查找。

3、依赖关系图

希望所有的用户故事为独立的，但是并不容易，仍会有一些依赖关系，如短时间的航运路线依赖于天气预、历史记录等等。

4、需求管理数字化平台。

6.5 提高团队协作管理

可以采用：团队共享日历、团队回顾、可视化故事墙、持续集成、故事验证等工具方法。

团队共享日历为成员时间表；团队回顾是对成员过去时间的团队协作的总结；可视化故事墙为项目流程如待开发、开发中、待测试、测试中、测试完成等项目的状态墙；故事验证流程为：共识-开发-自测-迷你验收-故事验收。

七、部署流水线原则与工具设计

部署流水线是持续交付1.0的核心模式。对软件交付流程的可视化呈现方式，提交、构建、部署、测试、发布的整个流程，为团队提供可视化和及时反馈。下面均以GoCD为例：

7.1 简单部署流水线

1、初始部署流水线

构建提交。包含7个并行自动化任务：编译打包、代码规范、静态扫描和5个不同的自动化/集成测试用例集合，使用自动触发机制。
次级构建。包含两个并行自动阿虎功能测试集任务，运行与两类环境，即Window系统的IE浏览器和Linxu系统Firefox浏览器。
UAT部署。软件包部署到UAT（用户验收环境），测试工程师手动触发。
UAT结果。测试人员的手工验证。
性能测试。自动化性能测试，手动触发。
外部体验。Bate版本给外部企业用户体验。
上传版本。商业发布。

**每次提交代码，流水线的提交构建都会被自动触发。**不是都要走完七个流程。

7.2 部署流水线的设计与使用

1、流水线的设计原则

一次构建，多次使用。
与业务逻辑松耦合。（设计的一些部署脚本等与逻辑松耦合）
并行化原则。即使反馈错误信息，缩短反馈时间。
快速反馈优先。运行快的在前面，慢的在后面执行。
重要反馈优先。与原则4要权衡，反馈更有价值的优先。

2、团队的协作纪律

立即暂停原则。有问题立即暂停，修复该问题。
安全审计原则。受控环境的任何组件（源代码、二进制包、插件）等均已经通过审计。

7.3、部署流水线平台的构成

部署流水线几乎贯穿了整个持续交付8字环的验证环，涉及代码提交到生产环境部署的整个流程。

1、工具链总体架构

唯一受信源。无二义性，如：代码仓库、需求/缺陷管理仓库、制品库（可以找到对应源码和缺陷，类似于已构建的包）。
部署流水线平台。展示信息。
基础支撑服务层。如构建、测试、部署等等。

2、基础支撑服务的云化

编译构建管理服务。包含构建的任务管理、调度、构建集群管理与构建执行器。从代码中拉取，保存到制品库。
自动化测试管理服务。包含：测试任务管理、测试用例管理、测试集群管理、甚至有用例健康管理自动化服务（健康用例/不稳定用例）。
软件部署管理服务。测试环境和预发布环境都没问题，上生产就有问题，多半是因为生产与测试环境差异所致。
基础环境管理服务。为上面的3类服务提供环境准备、管理和监控服务。

7.4 研发团队遵循原则

软件包的取用必须通过受控源，任何角色之间禁止通过私有通道获取（email、即时通信）
尽可能和的一切流程自动化，持续优化执行时间。
每次提交能够自动触发部署流水线。
尽可能少用手动触发方式。
必须执行立即暂停原则。

八、利于集成的分支策略

8.1 版本控制系统的使用目的

追踪目录和文件的修订历史（修订包含三类：新增、修改和删除），4W，什么时间when、修改什么内容what、谁修改的who、为什么改why。

1、集中式版本控制系统（如：SVN）

2、分布式版本控制系统（可以提交到本地而无需经过服务器，如：Git）

3、基本概念：代码仓库（codebase）、分支（branch）、主干（master）、版本（revision）、标签（tag）、头（head）、合入（merge）、冲突（conflict）

8.2 常见分支开发模式

1、主干开发，主干发布

要允许未实现的代码提交到将要发布的版本里，但是不能影响用户的正常使用和发布。

2、主干开发、分支发布

完全开发完成的模块，拉去一个分支，修复缺陷，质量达标后通过分支发布。与该版本无关的人员可以继续操作master不受版本影响，但是若要发布的版本没有在主干开发万，则不能创建发布分支，会影响下一个开发计划。

3、分支开发、主干发布

最常用的。主干拉分支开发，修复bug，质量达标后何如master并发布。分支开发不受影响，更加灵活，若出现缺陷可以直接在主干修复，无需考虑分支。

特性分支模式。根据功能特性开辟分支，完成后立刻合入主干，开发编码，联调自测，缺陷修复，合入分支。（与目前类似）
团队分支模式。大型团队，合入主干代码质量要高，即使不发布；合入主干后要尽快达到可交付状态；尽早合并。

8.3 分支演化

1、三驾马车分支模式。

仅仅维护3个分支：开发分支、预发布分支、发布分支。如Chrome在10年采用这种分支。Alpha版本发布给少量用户体验 >> 进一步发布Beta版本给尝鲜用户 >> 发现问题修复后，最后Bate稳定后，发布RC版本 >> RC稳定后即为正式发布。

2、GitFlow模式。

目前较多企业采用的方式，清晰但是分支较多。

Master是正式版本发布的分支
Release是用于质量打磨的预发布分支，若Release质量达标则合入Master分支，同时合入Development分支
Development分支是对新功能集成的分支
Feature是为例开发某一功能特性，开发从Development分支拉去的分支，开发完成后合入Development
Hotfix是对于已经发布的Master分支上拉出的分支，在这个分支上修复缺陷，验证后再合入Master分支，并发布补丁版本。同事也要移植Hotfix到Development分支上。

3、GitHubFlow模式

8.4 分支策略的选择

1、版本发布模式（特性、时间、质量）

项目制定发布模式。

针对特定版本，确定特性数量和质量标准，评估时间，再估计版本交付周期。交付周期较长，遇到需求变更需要重新评估项目交付时间，影响原有的其他项目按期交付，即所有需求全部实现才可以交付。
发布火车模式。

定好每个发布周期，实现规划好发布时间，类似火车时刻表。企业可以并行多条火车，突发需求排入到某一列火车。用户可以提前体验新产品的特性，不影响原有版本。
城际快线模式。

固定时间和质量两个维度，时间周期较短，针对发布时间点已经达到固定质量标准的特性记性一次发布。与火车的区别在于：①发布周期短，两周以内②负责特性开发的团队可以选择达成那一辆城际快线，无需提前确定时间。时间点更清楚，并更聚焦于生产质量。

对代码的提交质量要求更高，城际列车的周期可以安排为原有周期的一半（一个月、两周）。

2、持续交付2.0的分支模式原则

分支越少越好，最好只有一条主干
分支生存周期越短越好，最好3天以内
业务允许前提下，发布周期越短越好

九、持续集成

持续集成 ≠ 敏捷开发

9.1 定义

2、持续集成的实践，直接提现了快速验证环的基本工作原则，即“质量内建，快速反馈”。通过自动化的方式运用大量的质量检测项目（自动化测试、代码规范检测、代码安全扫描等）

9.2 六步提交法

1、六部提交法

检出最近成功提交的代码
在本地进行修改
第一次个人构建，保证个人构建没有问题
第二次个人构建，确认自己的代码和其他人merge后没有问题（如果不愿意做两次，就保留这一次）
提交代码到团队主干
提交构建

2、自查表【★】

检查是否达到持续集成的最佳状态

主干开发，频繁提交
每一次提交应该是一个完整的任务
让提交构建在10分钟内完成
提交构建失败后应禁止团队成员提交新代码，也不允许其他人检出该代码
立即在10分钟内修复已是北海的提交构建，否则回滚代码
自动化构建验证通过后，对软件质量有比较大的信心

十、自动化测试策略与方法

持续集成至关重要的部分就是自动化测试策略。

10.1 自动化测试的自身定位

测试领域有4类基本活动：问题认知、分析、执行和决策。“执行”环节存在大量重复劳动。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NybiMomu-1632932686629)(58DA2DB8AF37447EB596EAF2827EE9EE)]

1、自动化测试的优势

减少失误率，提高准确性。
节省时间和执行成本。
提升测试覆盖度。测试深度和范围，如查看内存使用，内存中数据表等等。
做手工无法完成的测试。
为开发人员提供高质量反馈速度。节省开发人员时间。
提高团队士气。更多的时间花在更具挑战性和更有价值的活动上，如探索性测试。

2、自动化的成本。

工具投入成本
用例维护成本
专业技能人员的成本。（学习成本）
设备资源的投入。（自动化测试环境的搭建等）

所以执行次数越多，平均下来，每次的自动化成本越低。若仅仅需要一次质量测试，无疑是手工测试的收益更大，若需要频繁回归，则自动化测试收益一定更大。

10.2 传统自动化测试困境

1、传统自动化测试的困境

2、持续集成过程中的自动化

快速。执行速度快，直接导致反馈速度快。
便捷。随时执行，否则会倾向推迟反馈。
及时。功能发生改变，立刻可以通过自动化的方式来对原有功能验证。
可信。自动化测试用力运行后的结果可信，不存在随机失败的现象，测试用力运行稳定。

3、测试金字塔

谷歌测试金字塔，大中小用例的占比10%、20%、70%。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FPsmZw7A-1632932686629)(AA5D7670375E4328B6B2F608D5B60CFC)]

微核架构的测试金字塔

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6KH0PZhL-1632932686630)(FB4A5F5C4668431385C95B4E74601EB0)]

微服务架构的测试金字塔

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EIAMupqS-1632932686630)(D9231338D34244318C93DE6ECCBC3648)]

（1）业务组件或者服务测试。单个组件或者服务的测试，验证该组件行为是否符合设计预期。

（2）契约测试。快速地验证消费者和服务提供者之间交互的基本正确性。

（3）业务工作流测试。是指启动运行两个或以上微服务，进行业务流程上的测试，以验证多个被测服务之间是否可以正常工作，完成某一业务请求。

（4）端到端测试。整个软件服务的流程进行测试，验证工作流符合设计预期。

10.3 自动化的实时策略

1、增加自动化测试用力的着手点。

对代码热区写自动化，投产比更高；跟随新功能写自动化；从金字塔的中间层向两端扩展，如契约测试向业务组件测试扩展；自动化质量大于数量。

2、提高自动化执行次数。

共享代码，团队收益；开发使用自动化，成为开发日常工具。

3、良好的自动化测试特征。

用例之间相互独立；测试用例的运行时稳定的；测试用例的执行速度快；测试环境应该统一（多环境均可运行）。

4、共享自动化测试的维护职责。

自动化代码随着需求的更新而更新，与需求变更速度一致。

5、代码覆盖率。

测试覆盖度，但是会提供一种错误的安全感。

十一、软件配置管理

11.1 一切纳入配置管理

1、配置管理范围【】

一切皆有版本

应用软件层、标准软件层、基础操作系统、测试工具、测试数据、测试代码、测试脚本等等都要有版本变更管理。EG：搭建测试环境。
共享唯一受信源

所有人获取的信息是一致的。统一的需求仓库、代码仓库、软件包仓库。历史产物仓库也要作为唯一软件包受信源。
标准化与自动化

基线管理，又有仓库员某一时刻的快照。

2、版本管理确认点

产品源代码和测试代码是否放入版本控制系统
软件应用的配置信息是否放入版本控制系统
各类环境的系统配置是否放入版本控制系统
自动化构建和部署脚本是否放入版本控制系统
软件包是否进行版本管理。

3、环境准备的4种状态

蛮荒以“人脑＋手工”为代表。
规范化以“文档＋私有脚本”为代表。
标准化以“办公自动化”为代表。
自动化以“受控式自动化脚本”为代表。

十二、低风险发布

12.1 高频发布是一种趋势

一大堆企业高频发布，引出降低发布风险的方法

12.2 降低发布风险的方法

1、蓝绿部署

准备两套完全一致的运行环境，一套为正式环境，提供对外服务，一套为预生产环境，部署软件新版本，并做验收测试。确认没有问题后，引流到新的版本所在的服务环境，该作为正式的生产环境。直到没有问题后，改以前的生产环境作为预生产环境。

最好有不同的WEB>SERVICE>SQL（理想状态）但是一般SQL会为一个库。

2、滚动部署

服务集群中选择一个或者多个服务单元，停止服务后进行版本更新，再投入使用，直到所有服务都到新版本。优势为成本低（相对于蓝绿部署），但是出现问题后无法像蓝绿部署一样切换到旧环境，而是需要回滚服务。

3、金丝雀发布与灰度发布

小部分用户线使用新版本，就是灰度。金丝雀就是（地下矿工故事）

4、暗部署

设置开关，所谓的“暗”指的是对用户无感知。验证新算法，配置开关，用户未知情况下请求访问，若不好，则关闭开关。

也可以采用流量克隆的方式来验证，请求克隆后访问。

12.3 高频发布支撑技术

1、快速迭代

主干开发，主干发布是更经济的做法。若某个功能复杂，无法在两次发布之间完成开发，如何解决/p>

拆分功能。拆分为迭代周期可以交付的子功能。
先后再前。实现用户不可见的部分，用户无入口，不影响原有功能。可以采用暗部署和流量克隆验证质量。
功能开关技术。通过开关隐层未开发完成的功能。（常用，类似于Apollo配置）

2、数据迁移技术

只增不删。用于扩展字段时。
数据迁移。数据库结构变化，建立仓库>双库同写>原有数据迁移>对比数据>保留旧数据库，只写新的数据库。

十三、监测与决策

13.1 生产监测范围

》资源监测、应用监测、业务监测。

1、如：后台服务监测

基础监测：基础设施健康度，络节点、络连接、拥堵、CPU负载、内存占用。
应用监测：程序的运行健康度，是否存在，是否对外提供服务，数据库连接正常、有误异常警告。
业务监测：业务指标的监测，浏览量、转化率、订单量、交易频率等。

13.2 数据监测体系

1、环节

都包含：收集、上、整理、分析、展现、决策

2、衡量维度

准确性、全面性、及时性。

13.3 问题处理体系

1、告警海洋

告警太多，若均处理则对工作干扰。对告警设置阈值，根因分析，根源解决，解决告警也是学习过程。

告警海洋的优化：

通过关联分析，让监控点离问题发生地更近
通过动态阈值设定合理的告警
定期梳理告警设置，清理不必要的告警
通过人工智能动态接触告警
对问题处理流程的最后两步，【根因分析】和【根源解决】，是学习型组织的重要特征

13.4 生产环境测试

1、测试右移

测试右移更多见于软件的展示功能，如搜索软件、拍照软件、新闻推荐、游戏性软件等，会对品牌造成影响，但是即使修复不会产生本质损失。

2、混沌工程

生产环境注入“问题”，发现生产系统的弱点，类似于疫苗，注射小量病毒提升免疫。如处理云计算问题，可以模拟某个区出现问题，或者人为制造延迟等等。

13.5 向东向西

业务闭环，决定方向。

十四、大型互联团队的FT化

FT（Feature Team,全功能团队），十五十六章是十四章的例子。

持续改进后，团队可以做到一天双发，每周有一个符合全标准的候选发布版本。

14.2 改进方法论

1、指导思想

目标驱动，从简单的问你开始，持续改善。

2、改进步骤

14.3 改进历程

1、架构解耦

2、组织解耦

3、研发流程再造

4、自动化一切

十六、研发推动的DevOps

十七、胜任力模型与组织健康度

17.1 组织能力三要素：流程、工具、个体

17.2 组织胜任力评估模型

1、过程维度

类似于马龙的六边形战士。它包含12个子维度，对不同维度评分综合得出。

2、结果维度

包含：质量、速度、吞吐率

质量：交付前，创建于修复的缺陷分布、缺陷数；交付后，生产环境单位时间的缺陷数量，运维时长
速度：业务响应速度，需求前置时间，研发周期，发布周期、发布频率与失败率、生产问题发现到修复的时间
吞吐率：单位时间的价值

17.3 个人胜任力培养体系

广泛知识（基层员工）、专项技能（基层骨干）、组织实施（中层管理）、目标规划（高层领导）

17.4 组织健康度

安全、信任、持续改善文化，见第四章。

【根源解决】，是学习型组织的重要特征