持续交付2.0:业务引领的DevOps精要(增订本)电子书

内容提要

序 一

序 二

自 序

前 言

读者对象

内容简介

阅读方法

致 谢

服务与支持

提交勘误

与我们联系

关于异步社区和异步图书

第1章 持续交付2.0

1.1 软件工程发展概述

1.1.1 瀑布软件开发方法

1.1.2 敏捷软件开发方法

1.1.3 DevOps运动

1.1.4 持续交付1.0

1.2 持续交付2.0

1.2.1 精益思想

1.2.2 双环模型

1.2.3 4个核心原则

1．坚持少做

2．持续分解问题

3．坚持快速反馈

4．持续改进并衡量

1.2.4 持续交付七巧板

1.3 小结

第2章 价值探索环

2.1 探索环的意义

2.2 探索环的4个关键环节

2.2.1 提问

2.2.2 锚定

2.2.3 共创

1．量化式影响地图

2．用户旅行地图

2.2.4 精炼

2.3 工作原则

2.3.1 分解并快速试错

2.3.2 一次只验证一点

2.3.3 允许失败

2.4 共创与精炼的常用方法

2.4.1 装饰窗方法

2.4.2 最小可行特性法

2.4.3 特区法

2.4.4 定向探索法

2.4.5 稻草人法

2.4.6 最小可行产品法

2.5 实施注意事项

1．多角色参与探索

2．存在往复过程

3．风险不是等价的

4．上帝视角

5．唯数字论

6．蛇行效应

2.6 小结

第3章 快速验证环

3.1 验证环的目标

3.2 验证环的4个关键环节

3.2.1 构建

1．时间盒管理

2．任务分解

3．持续验证

3.2.2 运行

3.2.3 监测

3.2.4 决策

3.3 工作原则

3.3.1 质量内建

3.3.2 消除等待

1．通过“拉动”让价值流动起来

2．任务自助化

3.3.3 重复事务自动化

3.3.4 监测一切

3.4 小结

第4章 持续交付2.0的组织文化

4.1 安全、信任与持续改善

4.1.1 失败是安全的

4.1.2 相互信任

4.1.3 持续改善

4.2 文化塑造四步法

4.2.1 行为决定文化

4.2.2 谷歌的工程师质量文化

4.2.3 Etsy的持续试验文化

4.3 行动原则

4.3.1 价值导向

4.3.2 快速验证

4.3.3 持续学习

1．定期回顾

2．复盘机制

4.4 度量原则

4.4.1 度量指标的4类属性

1．引导性指标与结果性指标

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

4.4.2 度量的目标是改善

4.4.3 古德哈特定律

4.4.4 度量应有行动决策

4.5 “改善套路”进行持续改进

4.6 小结

第5章 持续交付的软件系统架构

5.1 “大系统小做”原则

5.1.1 持续交付架构要求

5.1.2 系统拆分原则

5.2 常见架构模式

5.2.1 微核架构

5.2.2 微服务架构

5.2.3 巨石应用

5.3 架构改造实施模式

5.3.1 拆迁者模式

5.3.2 绞杀者模式

5.3.3 修缮者模式

5.3.4 数据库的拆分方法

5.4 小结

第6章 业务需求协作管理

6.1 产品版本周期概述

6.1.1 准备期

6.1.2 交付期

6.2 需求拆分的利与弊

6.2.1 需求拆分的收益

1．建立共识，协调工作

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

3．低成本拥抱变化

4．多次集成，及时反馈质量

5．鼓舞团队士气

6.2.2 需求拆分的成本

1．需求拆分时的显式成本

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

6.3 需求拆分方法

6.3.1 需求的来源

6.3.2 技术债也是需求

6.3.3 参与需求拆分的角色

6.3.4 不平等的INVEST原则

6.3.5 五大拆分技法

1．路径拆分法

2．按接触点拆分

3．按数据类型或格式拆分

4．按规则拆分

5．按探索路径拆分

6.3.6 七大组成部分

6.4 需求分析与管理工具集

6.4.1 用户故事地图

6.4.2 用户故事树

6.4.3 依赖关系图

6.4.4 需求管理数字化平台

6.5 团队协作管理工具

6.5.1 团队共享日历

6.5.2 团队回顾

6.5.3 可视化故事墙

6.5.4 明确“完成”的定义

6.5.5 持续集成

6.5.6 故事验证

6.6 小结

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

7.1 简单的部署流水线

7.1.1 简单的产品研发流程

7.1.2 初始部署流水线

7.1.3 流水线执行状态解析

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

7.2.1 流水线的设计原则

1．一次构建，多次使用

2．与业务逻辑松耦合

3．并行化原则

4．快速反馈优先

5．重要反馈优先

7.2.2 团队的协作纪律

1．立即暂停原则

2．安全审计原则

7.3 部署流水线平台的构成

7.3.1 工具链总体架构

1．唯一受信源

2．部署流水线平台

3．基础支撑服务层

7.3.2 平台应当具备的基本能力

7.3.3 工具链建设策略

7.4 基础支撑服务的云化

7.4.1 基础支撑服务的协作过程解析

7.4.2 编译构建管理服务

7.4.3 自动化测试管理服务

7.4.4 软件部署管理服务

7.4.5 基础环境管理服务

7.5 企业制品库的管理

7.5.1 制品库的分类

1．临时软件包库A

2．正式软件包库B

3．外部软件包库X

4．临时镜像库C、正式镜像库D与外部镜像库Y

7.5.2 制品库的管理原则

7.6 多种多样的部署流水线

7.6.1 多组件的部署流水线

7.6.2 个人部署流水线

7.6.3 部署流水线的不断演进

7.7 为开发者构建自助式工具

7.8 小结

第8章 利于集成的分支策略

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

8.1.1 集中式版本控制系统

8.1.2 分布式版本控制系统

8.1.3 版本控制系统中的基本概念

8.2 常见分支开发模式

8.2.1 主干开发，主干发布

8.2.2 主干开发，分支发布

8.2.3 分支开发，主干发布

1．特性分支模式

2．团队分支模式

8.3 分支模式的演化

8.3.1 “三驾马车”分支模式

8.3.2 Gitflow分支模式

8.3.3 GitHubFlow分支模式

8.4 分支策略的选择

8.4.1 版本发布模式

1．项目制发布模式

2．发布火车模式

3．城际快线模式

8.4.2 分支策略与发布周期的关系

8.5 小结

第9章 持续集成

9.1 起源与定义

9.1.1 原始定义

9.1.2 一次集成过程

9.2 六步提交法

9.2.1 4个关键点

1．六步提交法中的3次验证有什么作用

2．个人验证一定要做两次吗

3．如何确保在提交前执行个人构建

4．每次构建应该包含哪些质量验证内容

9.2.2 同步与异步模式

9.2.3 自查表

1．主干开发，频繁提交

2．每次提交应该是一个完整的任务

3．让提交构建在10分钟以内完成

4．提交构建失败后应禁止团队成员提交新代码，也不许其他人检出该代码

5．立即在10分钟内修复已失败的提交构建，否则回滚代码

6．自动化构建验证通过后，对软件质量有比较大的信心

9.3 速度与质量的权衡

9.3.1 分级构建

9.3.2 多人同时提交的构建

9.3.3 云平台的威力

9.4 在团队中实施持续集成实践

9.4.1 快速建立团队的持续集成实践

1．构建脚本化，搭建持续集成框架

2．向构建中添加已有的自动化验证集合

3．选择利于持续集成的分支策略

4．建立六步提交法

5．持续优化

6．工程师改变习惯，并提升技能

9.4.2 分支策略与部署流水线

1．“主干开发，主干发布”策略

2．“主干开发，分支发布”策略

3．“分支开发，主干发布”策略

4．多组件集成策略

9.5 常见的实施问题

9.5.1 工程师的开发习惯

9.5.2 视而不见的扫描问题

9.5.3 自动化测试用例的缺乏

9.6 小结

第10章 自动化测试策略与方法

10.1 自动化测试的自身定位

10.1.1 自动化测试的优势

10.1.2 自动化测试所需的投入

10.2 突破传统自动化测试的困境

10.2.1 传统自动化测试的特点

10.2.2 自动化测试的分层

10.2.3 不同类型的测试金字塔

1．微核架构的测试金字塔

2．微服务应用的测试金字塔

10.3 自动化测试的实施策略

10.3.1 增加自动化测试用例的着手点

1．针对代码热区补充自动化测试用例

2．跟随新功能开发的进度

3．从测试金字塔的中间层向上下两端扩展

4．自动化测试用例的质量比数量重要

10.3.2 提高自动化测试的执行次数

1．共享自动化测试用例

2．开发人员是自动化测试的第一用户

10.3.3 良好自动化测试的特征

1．用例之间必须相互独立

2．测试用例的运行结果必须稳定

3．测试用例的运行速度必须快

4．测试环境应该统一

10.3.4 共享自动化测试的维护职责

10.3.5 代码测试覆盖率

10.4 用户验收自动化测试要点

10.4.1 先搭建分层框架

10.4.2 测试用例数应保持低位

10.4.3 为自动化测试用例预留API

10.4.4 为调试做好准备

10.4.5 测试数据的准备

10.5 其他质量检查方法

10.5.1 差异批准测试方法

10.5.2 代码规范检查与代码动静态检测

10.5.3 AI在测试领域的应用

10.6 小结

第11章 软件配置管理

11.1 将一切纳入软件配置管理

11.1.1 软件配置管理的目标

11.1.2 软件配置管理的范围

11.1.3 软件配置管理的原则

1．一切皆有版本

2．共享唯一受信源

3．标准化与自动化

11.2 软件包的版本管理

11.2.1 包管理的反模式

11.2.2 集中式包管理服务

11.2.3 软件包的元信息

1．自身唯一标识信息

2．来源信息

3．依赖关系信息

11.3 包依赖管理

11.3.1 显式声明依赖

11.3.2 自动管理依赖

11.3.3 减少复杂依赖

1．依赖过多或者链条过长

2．依赖冲突

3．循环依赖

11.4 环境基础设施管理

11.4.1 环境准备的4种状态

1．以人脑+手工为代表的“蛮荒状态”

2．以文档+私有脚本为代表的“规范化状态”

3．以办公自动化为代表的“标准化状态”

4．以受控式自动化脚本为代表的“自动化状态”

11.4.2 领域专属语言的应用

11.4.3 环境基础设施即代码

11.5 软件配置项的管理

11.5.1 二进制与配置项的分离

11.5.2 配置信息的版本管理

11.5.3 配置项的存储组织方式

11.5.4 配置漂移与治理

11.6 不可变基础设施与云应用

11.6.1 实现不可变基础设施

1．物理机镜像技术和虚拟机镜像技术

2．Docker容器技术

11.6.2 云原生应用

11.6.3 优势与挑战

11.7 数据的版本管理

11.7.1 数据库结构变更

11.7.2 数据文件

11.8 需求与源代码的版本关联

11.9 小结

第12章 低风险发布

12.1 高频发布是一种趋势

12.1.1 互联网企业的高频发布

12.1.2 收益与成本共存

12.2 降低发布风险的方法

12.2.1 蓝绿部署

12.2.2 滚动部署

12.2.3 金丝雀发布与灰度发布

12.2.4 暗部署

12.3 高频发布支撑技术

12.3.1 功能开关技术

12.3.2 数据迁移技术

1．只增不删

2．数据迁移

12.3.3 抽象分支方法

12.3.4 升级替代回滚

12.4 影响发布频率的因素

12.5 小结

第13章 监测与决策

13.1 生产监测范围

13.1.1 后台服务的监测

13.1.2 分发软件的监测

13.2 数据监测体系

13.2.1 收集与处理

13.2.2 数据的标准化

13.2.3 监测数据体系及其能力衡量

13.3 问题处理体系

13.3.1 告警海洋与智能化管理

13.3.2 问题处理是一个学习过程

13.4 生产环境测试

13.4.1 测试活动扁平化趋势

13.4.2 生产环境中的测试

13.4.3 混沌工程

13.5 向东，还是向西

13.6 小结

第14章 大型互联网团队的FT化

14.1 简介

14.1.1 改进前状态

1．团队组织结构

2．版本研发节奏

14.1.2 改进后状态

1．团队组织结构

2．版本研发节奏

14.2 改进方法论

14.2.1 指导思想

14.2.2 改进步骤

14.3 改进的历程

14.3.1 架构解耦

14.3.2 组织解耦

14.3.3 研发流程再造

1．多版本发布的目的与原则

2．虚拟主干的混合分支模式

3．建立统一制品库

4．两级发布体系

5．版本质量管理机制

6．多业务协同发布机制

7．编译构建云平台

14.3.4 自动化一切

14.4 小结

第15章 小团队逆袭之旅

15.1 背景简介

15.1.1 改进前的“死亡行军”之旅

15.1.2 改进后的无缺陷交付

15.2 改进方法论

15.2.1 指导思想

15.2.2 试点团队的选择

15.3 第一阶段：研发准备期

15.3.1 功能简介与需求拆分

15.3.2 架构设计与需求依赖识别

15.3.3 工作量估算与排期

15.4 第二阶段：软件交付期

15.4.1 通过可视化看板改进工作流程

1．识别坏味道

2．让价值流动起来

3．显式声明“完成”的标准定义

4．涂鸦设计，消除浪费

5．明确状态，关注需求的快速流动

6．避免不必要的任务切换

7．没有反馈，就是“风险”

8．限制在制品数量

15.4.2 无缺陷交付

15.4.3 主干开发与持续集成

15.4.4 测试活动左移

15.4.5 代码评审

15.4.6 关注结果，更要关注过程

15.5 小结

第16章 研发推动的DevOps

1．案例背景

2．原有的工作模式

16.1 改进的关键点

16.1.1 改进方法论

16.1.2 定义改进目标

1．部门负责人的期望

2．团队管理者的交付压力

3．项目负责人的烦恼

16.2 第一阶段：敏捷101

16.2.1 做个靠谱的计划

1．需求拆分

2．相对估算

3．初始计划

16.2.2 开发阶段启航

1．迭代周期的选择

2．团队协作流程

16.2.3 对过程质量的约束

1．如何能自觉遵守CI纪律

2．编译时间过长

3．开发人员无法运行自动化测试

4．自动化测试的策略

5．自动化测试所需的运行环境不足怎么办

6．如何确定一个需求可以提测

7．如何做性能和压力测试

16.2.4 阶段性改进点

16.3 第二阶段：DevOps转型

16.3.1 与运维人员的“冲突”

16.3.2 高频部署发布中的具体障碍

16.3.3 整体解决方案的设计

1．自动化测试策略的调整

2．自动化测试的便捷性

3．测试代码的同源

4．配置管理优化

5．软件包管理

6．部署与监控的优化

16.3.4 DevOps阶段的团队改变

16.4 小结

第17章 研发组织效能提升的必经之路

17.1 知识工作者与熵增定律

17.1.1 每个工程师生产的都是非标品

17.1.2 软件工程的复杂性令研发效率降低

17.2 一致性是效能提升的必经之路

17.3 组织能力三要素

17.4 胜任力评估

17.4.1 组织胜任力评估模型

1．过程维度

2．结果维度

17.4.2 个人胜任力培养体系

17.5 组织健康度

17.6 小结

附录A 软件工程的三次进化

A.1 软件工程的诞生

A.1.1 软件危机

A.1.2 瀑布软件开发模型

A.2 二次进化：敏捷开发

A.2.1 前奏——螺旋模型

A.2.2 敏捷宣言的诞生

1．Scrum框架

2．极限编程方法

A.2.3 敏捷软件开发方法的演化

1．Scrumban框架

2．SAFe框架

3．LeSS框架

4．Nexus

A.2.4 敏捷软件开发方法小结

A.2.5 TPS启发下的软件开发方法

1．精益软件开发方法

2．看板方法

A.3 三次进化：DevOps

A.3.1 DevOps运动的兴起

A.3.2 持续交付的诞生

A.4 小结

附录B 排序法做相对估算

B.1 排序法相对估算

1．相对估算的难点

2．使用目标

3．曾使用过的场景

4．该方法的假设

B.2 相对排序法的操作过程

1．第一步：准备工作

2．第二步：初步排序

3．第三步：讨论差异

4．第四步：确定工作量大小刻度

5．第五步：归并调整

6．使用注意事项

B.3 小结