持续交付2.0 思维导图模板_ProcessOn思维导图、流程图

1.什么是持续交付2.0

持续交付1.0

能够以可持续的方式，安全、快速的吧代码变更（包括特性，配置，缺陷，和实验）部署到生产环境，让客户使用。

关注从代码到发布

持续交付2.0

持续交付1.0 + 精益思想，强调IT与业务的闭环，识别和消除一切浪费的理念，通过一系列原则与实践帮助企业以可持续的方式高质量、低成本无风险的对客户交付价值。

关注8字双环周期和四个核心原则

八字双环模式

探索环

提问

锚定

共创

精炼

验证环

构建

运行

监测

决策

四个核心原则

坚持少做

持续分解问题

坚持快速反馈

持续改进并测量

持续交付七巧板

业务需求协作管理

自动化验证管理

分支与配置管理

构建与环境管理

部署发布与监测管理

文化建设、组织架构、人员架构、激励体系

易测试性、易部署性、易扩展性、易监控性

2.价值探索环

1.为什么要有探索环

项目成功依赖于三项成功的假设，而市场变化是很快的

用户假设

我们的产品服务于某一类潜在客群

问题假设

我们理解客群是存在某一痛点的

解决方案假设

我们的解决方案可以解决这个痛点

任何一个假设不成立，或事倍功半，或无功而返

我们借助探索环，来验证我们成功的三项假设

2.探索环的组成

提问

目标

实现什么

如何实现

为什么实现

* 技术人员的角色惯性会让我忽略最重要的问题，为什么要实现

锚定

目标

确定具体的目标和结果，并将其分解

不可度量的目标企业希望用户喜欢他提供的信息服务

可度量的目标1. 单个用户使用时长

可度量的目标2.单个用户推荐比例

可度量的目标3. 单位时间内在线用户总数

项目成功标准是可度量的价值指标

共创

目标

找到到达锚定目标的路径

方法

量化式影响地图

影响地图：why - who- how -what分析法

why

who

how

what

how

what

who

how

what

量化式影响地图

目标

角色

影响

方案

量化

用户旅行地图

可视化的方式，按流程图分阶段呈现

接触点

接触阶段

痛点

情绪

误区

过度分析导致分析瘫痪

过多细节导致完美方案

精炼

评估共创结论，筛选出最小可行性目标达成路径

3.减速探索环运转

1.快速试错

2.每次只验证一个特性

3.允许失败

4.共创和精炼方法

装饰窗

最小可行特性

特区法

定向探索法

稻草人法

最小可行产品法

3.快速验证环

前提

进入验证环的前提是，团队已经形成共识，所选方案为当前环境下验证或者解决领域问题的最佳方案。

目标

借助各种方法或工具，让解决方案快速的到达用户手中，并收集和分析真实反馈

4个关键环节

构建

时间盒管理

任务分解

持续验证

运行

不遗余力的将重复工作自动化

监控

指标

收集方式

模型

决策

工作原则

质量内建

过程或者特性的每个中间产物，都需要符合对应的质量标准

避免通过大规模的质检来监测质量

消除等待

精益的思想：等待属于浪费行为

通过拉动来消除等待

通过自动化建设来消除等待

重复事物自动化

构建环境

回归测试

应用部署

......

监测一切

至少需要

应用健康监测

业务健康监测

4.组织文化

1.安全、信任与持续改善

1.安全

没有人能够一直正确

尽早发现失败行为对组织来说是安全的

失败的惩罚会导致成员缺乏组织安全感进而会导致合作的减少

2.信任

通过不断的成功合作产生信任

信任他人，同时需要通过自己的技术能力、专业素养、承诺履行等行为赢得他人信任

3.持续改善

人人参与

时时改善

2.文化塑造四步法

通过文化来改变行为是低效的

通过行为来改变文化是高效的

四步法

定义要做的事情

定义期望的做事方法

提供相应的培训

做些必须的事情来强化这些行为

可以理解为审计、检查

案例 Etsy：持续实验文化

案例 Google：工程师质量文化

3.行动原则

价值导向

快速验证

持续学习

4.度量原则

无法测量，则无法改进。彼得德鲁克

指标设定

比较性

观测性和指导性

引领性和滞后性

度量的目的是改善

丰田改善四步法

1.明确方向

2.掌握当前状态

3.定义下一个目标

4.迭代改进

5.交付软件的系统架构

原则.大系统小做

持续交付架构原则

为测试而设计

为部署而设计

为监控而设计

为扩展而设计

为失效而设计

系统拆分原则

每个组件必须有明确的业务职责，可以被独立修改和替换

高内聚低耦合

易于构建与测试

易于协作

常见架构模式

插件模式

优

业务延展性好

易于发布

易于测试

定制化程度可以很高

可以渐进开发

劣

功能的扩展性差，不容易做成分布式

开发难度较高

高度依赖框架，框架的性能是瓶颈

微服务模式

优

功能扩展性好

易于部署、开发，可以独立测试

劣

高度强调低耦合，拆分成大量的微服务，系统庞大，笨重，且网络通讯消耗较大

原子操作带来困难

跨服务场景测试比较困难，对开发、测试环境的维护要求较高

需要建立全面的微服务监测体系

巨石模式

是单一结构体组成的软件应用，用户接口和数据访问绑定在同一语言平台的同一应用程序上，每一个巨石应用都是一个独立的系统

优

利于开发调试

容易扩展

技术栈单一，人力资源容易获取

劣

难于和新技术共同使用

新手容易产生混乱的代码

只能将整个应用作为一个整体扩展

架构改造实施模式

拆迁者

推到重来

修缮者

不创建新服务

优化服务内的能力

可以随时停止

不会造成历史需求的丢失

系统外无感知

绞杀者

创建新的服务

逐步重新服务内的能力并做迁移

时间跨度较大

有迭代成本

系统外有感知

数据库拆分

6.业务需求协作管理

需求拆分的收益

建立共识，协调工作

小批量交付，加速价值流动

低成本拥抱变化

多次集成，持续反馈系统质量

鼓舞团队士气

需求拆分的方法

需求的来源

来源

业务增长需求

非业务需求

安全性/合规性/战略性需求

阶段

backlog清单

细化过程中的新发现

缺陷

突发运营类

技术债

辅助测试类需求

invest原则

独立

independent

可协商

negotable

有价值

valuable

可估算

estimate

规模适中

small &amp; similar size

可验证

testable

inv&lt;est

五大拆分方法

路径拆分：支付：支付宝/微信/网银

接触点拆分：安卓/苹果/小程序/公众号/官网

按数据类型拆分：手工录入数据/文件导入数据/接口同步数据

按规则拆分：基础需求+完善需求

按探索路径拆分：针对陌生领域、且无专家协助的工作内容，属于高风险部分

需求组成

可参考敏捷用户故事描述方法

需求分析和管理工具

用户故事地图

按步骤 ------ 目标1(功能点) ------

用户故事树

系统、角色、特征集、用户故事

依赖关系图

确定用户故事的前后次序

需求管理平台

团队协作

共享日历

团队回顾

拉动式看板

完成定义

持续集成

故事验证

7.流水线部署原则与工具设计

设计原则

一次构建、多次使用

与业务逻辑松耦合，必要时可以牺牲一部分自动化

并行化原则

例如一次构建含有多组自动化测试套件

快速反馈优先

重要反馈优先

团队纪律

立即暂停原则

一旦发现构建失败，立即停止工作进行修复，保证部署流水线一直是可用状态

内建质量的体现：源自丰田的 stop the line

安全审计原则

制品或者制品要素来自受控环境

制品或者制品元素是经过审计的

尽可能早的对流水线进行审计

流水线具备的基本能力

可追溯能力

事件：什么时间，什么人，执行了什么操作，为什么执行、以及操作过程中执行的脚本是什么

可重建能力

可以快速构建或还原某一个版本的环境

8.利于集成的分支策略

Gitflow分支模式

master

hotfix

release

development

feature1

feature2

分支主题

9.持续集成

一次集成的过程

开发提交代码到仓库

持续集成服务器按一定的时间频率进行轮询，直至发现代码变更

检出到专用服务器

在专用服务器上使用构建脚本对最新代码进行检查

静态扫描

编译打包

运行单元测试

部署并运行功能测试

结束后将检查结果反馈给技术团队

六步提交法

检出最近成功的代码

修改代码

第一次个人构建

首先执行一个自动化验证集

得到自己本次修改内容是否达标

第二次个人构建

合并到当前版本，继续执行自动化验证集

得到本次代码合并是否达标

提交代码到主干

提交构建

构建失败则通知所有成员，并立即停止其他事务对本次构建进行修复，直至构建成功

分支主题

三个关键点

六步提交法必须包含三次验证

个人验证需要做两次

其中个人代码合并到主干之前必须做验证

每次构建需要验证的内容

二进制包是否包含了正确的内容

构建结果必须能够正常启动运行

主干业务流程必须能够正常运行

童子军法则：离开时的营地必须要到达之前一样干净，如果能更干净一点就更好了。

自查点

主干开发、频繁提交

每次提交一个完整的特性或者用户故事

尽量削减构建时间，最好控制在10分钟以内，否则考虑增强自动化能力

出问题之后，如果X分钟之内无法完成构建，则回滚代码，不要影响其他构建执行

自动化验证可以大幅提高团队质量信心

改变工程师的提交习惯，并提升技能

常见的实施问题

改变工程师的提交习惯，并提升技能

视而不见的扫描问题

扫描规则不一致

管理问题

太多了

至少不增加新的

严重问题deadline

自动化测试用例的缺乏

准入测试中，人工测试是一种慢反馈

依赖于自动化的基础建设

10.自动化测试策略与方法

增加着手点

代码热区

新特性

质量大于数据

提高执行次数

研发是自动化测试的第一用户

共享测试用例

良好的自动化测试特征

用例独立

结果稳定

执行速度快

环境统一

维护职责

破窗效应

代码覆盖率

谷歌建议指标：单元测试覆盖率85%

自动化验收测试

需要有自动化测试任务的调度系统

测试用例需要保持低位数

设计的时候，需要为自动化测试预留API

需要保留可用的执行产物，例如日志，截屏，数据

测试数据准备

12.低风险发布

常见的低风险发布方法

蓝绿发布

项目逻辑上分为AB组

首先把A组从负载均衡中摘除，进行新版本的部署。B组仍然继续提供服务

B组也升级完成，负载均衡重新接入B组，此时，AB组版本都已经升级完成，并且都对外提供服务

金丝雀发布

让一部分用户继续用老版本，一部分用户开始用新版本，如果用户对新版本没什么意见，那么逐步扩大范围，把所有用户都迁移到新版本上面来

暗部署

指软件特性在正式发布之前，先将其第一个版本部署到生产环境。通过应用“开关”技术，使用户在无感的情况下应用新特性的功能，软件提供商通过收集用户的实际操作记录来获得针对这个新特性的反馈数据

滚动部署

指从服务器集群中选择一个或多个服务单元，停止服务后执行版本更新，再重新将其投入使用。如此循环往复，直至在集群中所有的服务实例都更新到最新版本。

高频发布的辅助设施

开关策略

数据迁移方法

抽象分支策略