一、持续交付2.0

1.1软件工程发展：

瀑布开发 -> 敏捷开发

相比瀑布的线性模型，只有在项目交付后期才能看到可运行的软件，敏捷开发将一个交付计划划分为多个迭代，每个迭代结束都可以得到对应可运行软件。

1.2 DevOps:

是运维与研发参与整个软件生命周期的一组实践，它倡导对构建软件的所有环节（从集成、测试、发布、到部署和基础架构管理）进行全面的自动化和监控，从而达到更快、更频繁地交付更稳定的软件的目的。

1.3 持续交付1.0

可持续地快速发布软件服务。

持续交付1.0

1.4持续交付2.0

持续交付2.0双环模型

探索环：定需求。
验证环：落地功能。

以业务为导向，拆解细化业务问题，快速通过双环进行探索和验证，减少浪费的同时，快速找到业务前进方向。

二、价值探索环

目的：持续识别和定义有价值的假设，借助价值验证环得到数据反馈，快速把握业务前进方向。

4个关键环节：

• 提问：找出业务目标
• 锚定：收集信息量化指标，描述期望的结果。
• 共创：讨论出所有可行的解决方案。
• 精练：评估出合适方案作为验证环的输入。

为了加快探索环的速度，提出三点工作原则：

• 分解并快速试错
• 一次只验证一点
• 允许失败

共创与精练环节常用的方法：

• 装饰窗方法： 设计一个用户能看到但并没有实现的新功能入口，快速且低成本地验证用户是否喜欢某个功能及紧迫程度。
• 最小可行特性法： 产品的从1到N的过程。拆解任务，优先实现用户最迫切的需求。
• 特区法：在特定小范围用户群内验证某个新功能是否有效，减少无效或者效果不好带来的损失。
• 定向探索法：对具有特定行为的特定用户群，针对性设计调查方案，探索其行为动机，得出功能的定位或者改进方向。
• 稻草人法：不开发真实功能，但是先向用户提供该功能等价的真实效果。
• 最小可行产品法：产品从0到1的过程。以尽可能少的成本开发出产品核心功能，获取用户，并收集真实数据，不断锚定产品的方向和形态。

三、快速验证环

目的：借助各种方法与工具，让质量可靠的解决方案快速到达客户手指，进而收集并分析真实反馈。

4个关键环节：

• 构建：解决方案落地。
• 运行：交付产品，为用户提供服务。
• 监测：收集数据，并对系统进行监控。
• 决策：将收集的信息与探索环的期望目标进行对比，做出决策，确定下一步方向。

工作原则：

• 质量内建：生产过程中的每个环节都开展质量保障，而非到后期统一一次大规模检查。
• 消除等待：提升各环节效率，减少浪费。
• 重复事物自动化：重复性工作通过优化流程和自动化措施，降低成本。
• 监测一切：应用健康监测、业务健康监测。

对持续交付2.0双环模型理解：
价值探索环持续高效产出有价值的业务方案，作为输入给到快速验证环。
快速验证环快速高质量完成业务落地，交付用户，并收集有效反馈给到加载探索环。
价值探索环根据反馈信息与之前期望进行对比，做出决策，确认下一步方向。
这个大框架过程中，通过一切手段来保证更快的速度和更好的质量。

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

企业采纳持续交付需要的文化氛围：安全、信任与持续改善。

五、持续交付的软件系统架构

持续交付2.0能力对系统架构的要求：

• 可测试性
• 易部署性
• 易监测性
• 易扩展性
• 对可能失败的处理

常见架构模式：

• 微核架构：插件化，常用于客户端软件
• 微服务架构：后台服务软件
• 巨石架构：单一结构体组成的软件应用

架构改造实施模式：

• 拆迁者模式：重写一套新框架。
• 绞杀者模式：通过增加新服务来不断替代遗留系统功能。
• 修缮者模式：通过迭代，对原有遗留系统进行逐步改造，同时开发新的功能。

六、业务需求协作管理

产品版本周期主要分为：准备期和交付期。分别对应持续交付2.0双环模型的探索环和验证环。
重点讨论如何通过需求拆分带来更好收益，降低固定成本。

传统瀑布软件开发方式是按开发阶段来拆分的，该方案只有等到项目进入全面测试阶段才能得到可运行的软件包。我们应该尽可能从业务视角出发进行需求拆分，将需求按用户故事进行拆分，一批用户故事构成一个可交付的软件，不断迭代为完整用户故事构成的最终软件包。

因此合理拆分显得尤为重要，这里需要遵守INVEST原则：
*independent 用户故事独立

• negotiable 可协商
• valuable 用户故事必须是有价值的
• estimable 必现可估算创建用户故事的工作量
• small 用户故事必须足够小
• testable 用户故事必须是可被验证的

常用5大拆分方法：

• 按路径拆分法： 根据用户使用场景中的不同路径进行拆分，比如：支付场景的微信支付、支付宝支付可以拆分为两个用户故事分别实现。
• 按接触的拆分法：根据用户与系统间的交互通道进行拆分。比如：移动端、pc端。
• 按数据类型或格式来拆分：比如统计工具，实现文件上传。这里可以拆分为csv、xml、excel分别为三个上传功能来实现。
• 按规则拆分：业务规则或技术规则。基础需求->完善需求 递进。
• 按探索路径拆分：将对陌生事物的实验性探索逐步拆分为不同的探索故事。

团队协作管理工具:

• 团队共享日历： 团队时间管理。
• 团队回顾：定期复盘。
• 可视化故事墙：团队工作状态可视化（todo、doing、done）。
• 明确完成的定义：明确好交付的标准。
• 持续集成：团队多人并行开展工作，及时交阶段性交付成果持续集成。
• 故事验证：测试验收标准。

整体这一套团队协作管理方案其实就是敏捷开发。

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

部署流水线：它是对软件交付过程的一种可视化呈现方式，展现了从代码提交、构建、部署、测试到发布的整个过程，为团队提供状态可视化和及时反馈。

八、利于集成的分支策略

版本控制目的，回答4个W

• when 什么时间
• what 修改了什么内容
• who 谁修改的
• why 为什么要修改

主流版本管理系统：

• 集中式：单一的版本管理服务器。
• 分布式：对个服务器共存，每个人的节点都是一个代码仓库，所有节点都平等。

版本控制系统基本概念：

• codebase 代码仓库。
• branch 分支，选定代码基线创建的副本。
• master/trunk 主干。
• revision 对应某个分支的一次提交操作。
• tag 标签，某个分支的某个版本号的一个别名。
• head 某个分支最新一次提交。
• merge 合并分支内容。
• conflict 合入操作引发的冲突

常见分支开发模式：

• 主干开发，主干发布 基于主干开发，向主干提代码，主干持续作为功能交付分支。
• 主干开发，分支发布 基于主干开发，向主干提代码，从主干拉出交付功能分支，集成测试并修复bug，发布分支。
• 分支开发，主干发布 从主干拉出分支进行开发，开发完成对外交付版本时才合入主干分支。

分支模式的演化：

• "三驾马车”分支模式 开发分支->预发布分支->发布分支
• Gitflow分支模式 feature->dev->release->master/hotfix
• GitHubFlow分支模式 checkout feature branch from master -> dev on feature branch -> PR -> merge master

版本发布模式：
项目制发布模式 固定了版本特性数量和质量要求。
发布火车模式 大型项目，多条产品线，各团队对齐交付时间节点。
城际快线模式 固定时间和质量，满足发布条件的特性有多少就上多少。

选择分支模式原则：

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

九、持续集成

持续集成是一种软件开发实践，团队成员频繁地将他们的工作成果集成在一起，每次提交后，自动触发运行一次包含自动化验证集的构建任务，以便能尽早发现集成问题。

持续集成属于一种质量反馈机制。

持续集成过程

六步提交法：

• 检出最近成功的代码 checkout last build success branch
• 修改代码 do feature
• 第一次个人构建 build feature
• 第二次个人构建 pull origin branch ,merge code ,build again
• 提交代码到团队主干 PR
• 提交构建 server build

持续集成获得最大收益，做到如下六点：

• 主干开发，频繁提交代码。
• 每次提交都是完整有意义的工作。
• 提交构建阶段在10分钟内完成。
• 提交构建失败后，立即修复；且其他人不得在修复之前提交代码。
• 应该在10分钟内修复失败，否则回滚引起失败的代码。
• 自动化构建成功后，团队对软件质量比较有信心。