![《软件交付通识计算机与互联网软件工程及软件方法学董越软件产品的交付过程软件交付通识》[21M]百度网盘|亲测有效|pdf下载](/uploads/s0309/e1aabf52cde75e94.jpg)
软件交付通识计算机与互联网软件工程及软件方法学董越软件产品的交付过程软件交付通识
- 出版社:北京华夏学林图书专营店
- 出版时间:2021-10
- 热度:6851
- 上架时间:2024-06-30 09:08:33
- 价格:0.0
本站支持尊重有效期内的版权/著作权,所有的资源均来自于互联网网友分享或网盘资源，一旦发现资源涉及侵权，将立即删除。希望所有用户一同监督并反馈问题，如有侵权请联系站长或发送邮件到ebook666@outlook.com,本站将立马改正
编辑推荐
√ 系统剖析软件交付思维方式、过程和技术活动，集作者多年工作与研究之大成
√ 面向数字化转型时代，聚焦软件交付过程的标准化、自动化、自助化和可视化。
√ 10大策略，浓缩来自大型互联网及金融企业多年DevOps优化与业务敏捷实践。
√ 少见地针对软件交付多元化发展及企业组织级过程改进提供有益的指导和参考。
√ 不在孤立强调质量和效率，主张一切为了业务的成功，紧扣时间、效果和效率。
√ 内涵深刻、外延宽广，同时适合研发人员、产品经理、质量人员、团队管理者。
内容简介
软件交付过程是指在编程序改代码之后，直到将软件发布给用户使用之前的一系列活动，如提交、集成、构建、部署、等。本书作为通识类图书，对软件交付过程的各个方面进行了全面综合的介绍。这包括三部分内容：第1部分，介绍在研究软件交付过程时常见的思路和思考框架；第2部分，梳理软件交付的总体过程；第3部分，考查软件交付过程中的各个具体活动。总的来说，本书提供了一种类似于对人进行体检的方法，对特定软件产品的交付过程进行全方位的调研，可以根据其所在的业务领域、当前采用的技术栈、使用的工具、流程和方法等实际情况，找出当前突出、值得改进的问题。
作者简介
董越，DevOps专家，集团前研发效能事业部架构、产品专家等职，从事 Aone&云效 DevOps 产品设计、阿里云专有云集成与交付解决方案设计等工作。在加入阿里之前，他还曾就职于西门子、摩托罗拉、雅虎、索尼、去哪儿网等大型企业，一直从事软件配置管理、软件集成与交付、DevOps 相关的工作。当前主要从事企业级DevOps体系建设与咨询工作，帮助众多企业提升软件研发交付效能。已服务过的客户有华为、工商银行、交通银行、招商银行、中信银行、中国移动、中国联通、中国电信、华泰证券、泰康人寿等。
精彩书评
创新是生产要素的重组，技术创新是技术要素的不断分合。DevOps让开发与运维深度融合，微服务把一个大功能分割成多个小微服务。为了让开发人员和运维人员更加专注于自己的工作，位于开发和运维二者之间的软件交付就要相对独立出来，需要方法论。《软件交付通识》系统性地剖析了软件交付的思维方式、过程和技术活动，是作者多年工作与研究的智慧结晶。
——何宝宏 中国信息通信研究院云计算与大数据研究所所长
在数字化转型时代，如何高效地生产并交付软件，是非常重要的一部分。《软件交付通识》从历史实践，到目前的策略和可落地的实践案例，给出了全面的解释。《软件交付通识》兼具理论和实践，逻辑性较强，文字生动活泼，是企业软件交付工程师不可多得的百宝书。
——栗蔚 中国信息通信研究院云计算与大数据研究所副所长
一行代码的变更多久可以和用户见面？对软件企业来说，这个看上去简单的问题实际上是提高软件交付能力的核心点，软件交付过程的标准化、自动化、自助化和可视化水平，已经成为软件企业的核心竞争力。本书采用通俗易懂的语言，概括了几十年来软件工程领域的探索和实践，阐明了软件研发能力建设的思想和策略，详细介绍了软件交付过程中关键活动的关注点、原则和实现方法。本书线索清晰，结构简明，是一本非常实用的图书。
——温建波 中国工商银行软件开发中心项目办总经理
DevOps优化是整个金融云转型工程的核心主线和灵魂，也是企业数字化转型的重要手段。DevOps是一种工程实践，DevOps践行需要各行各业特别是金融行业相关经验的实践总结和归纳，本书作者在大型互联网公司从事相关工作多年，近年来也服务于各大银行等同业，给出了一种颇有价值的探索。
——万化 浦发银行信息科技部副总经理
软件交付是企业数字化能力的重要支撑之一。交付的质量和速度直接影响企业业务价值的实现和业务的成功。本书深刻详细地剖析了软件交付过程中的各种活动，融贯各种理念，给出了要求、原则和具体的方法，并辅助于场景例子。我在阅读这本书的时候，结合我们在金融软件交付中的实践和探索，深切地感受到书中的理念和方法引起的共鸣。这是一本全面丰富的软件交付很好实践的指引图书，它结合当前极新的软件技术，对软件交付中从组织到工程实践进行了详细说明和讨论，非常值得一读。
——黄威琪 平安银行总行首席架构师
数字化转型现在成为各行各业、企业的共识，而质效并举的软件交付又是业务敏捷及企业数字化转型的核心要素之一，特别是在云计算和云原生方兴未艾的，高水准的软件质量和交付效率成为业务成功的重要保障。本书结合互联网及金融等行业的典型实践，提炼出软件交付的10个策略，以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
前言/序言
推荐序
近年来关于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基金会中国区执行董事