1. 引言
本书的核心模式是部署流水线，以持续集成理论作为其理论基石
部署流水线有三个目标
- 让软件构建，部署，测试和发布过程对所有人可见，促进合作
- 改善反馈，能在整个过程中更早的发现和解决问题（做一件事，有问题发生是一定的，重要的是快速的定位和解决问题）
- 使在任何环境下部署和发布任意版本的应用成为自动化的过程，提高效率
一个简单的部署流水线
提交阶段 ==> 自动化验收测试 ==> 自动化容量测试 ==> 手工测试 ==> 发布
2. 一些常见的反模式
2.1. 反模式：手工部署软件
这个反模式一般具有如下特征
- 有一份详尽的操作文档，其中描述了多出需要注意的地方（呵呵，很多地方连操作文档都没有啊）
- 手工测试程序是否运行正确（懒，一不定会测，累，漏测了。。。）
- 总有客户来问，部署怎么又出问题了（金主生气，就问你紧不紧张）
- 如果是集群环境，个环境配置经常有出入（线上访问测试库）
- 发布过程时间较长（人的速度哪能跟计算机比啊）
- 发布结果无法预测（凭运气）
- 经常加班，还搞不定问题（恶性循环）
理想的部署流程应该是
- 挑选要部署的版本和环境
- 按一下“部署”按钮
为什么需要部署自动化
- 使部署过程可重复
- 免去部署文档的维护，一个部署脚本即是所有文档
- 部署过程可审计追踪，我有日志，别抵赖，呔，哪里跑
- 摆脱对人的过分依赖，让傻子也能上线
2.2. 反模式：开发完成之后才向生产环境部署
经常出现的情况
- 运维人员之前一直没有接触过应用程序，莫名其妙扔过来一个包，老子知道你是干嘛滴啊
- 程序相关的配置，数据库脚本，部署文档等都没有在正式环境下测试过（胆子真大）
- 开发团队和运维团队协作太少（除了互相甩锅没啥交流）
导致的各种问题
- 第一次部署成了噩梦（无准备之仗不好打啊）
- 开发环境和部署环境差距越大，问题越多（绝大部分问题都是不一致导致的）
- 各团队之间协作焦头烂额（可参照正规军与乌合之众的区别）
解决方案
将测试，部署和发布活动都纳入到开发过程中，让他们成为正常开发流程的一部分，对部署过程也进行测试（可以把部署当成一个产品来开发）
2.3. 反模式：生产环境的手工配置
这种反模式经常有如下特征
- 诶，我本地好使啊（呵呵）
- 集群中各节点表现不同（配置参数丢三落四）
- 每次准备环境时间长（上厕所，到咖啡）
- 无法回滚（要是真回滚了，估计产生更多问题）
- 不知不觉，集群中的服务器，操作系统配置变得都不一样了（人的脑子啊，是相当不靠谱的）
怎样解决这些问题？
采用配置管理，可以重复的创建开发应用程序所需要的每个基础设施
对于各个环境中的信息，都应该完全掌控，而且，所有环境的生成，配置的修改都应该由自动化程序实现，禁止手动修改（手动是万恶之源）
2.4. 如何改变这种情况
采用部署流水线，将软件的发布变成一种低风险、频繁、廉价、迅速且可预见的过程
最后的目标是实现将自动化的测试和部署，以及全面的配置管理结合在一起，实现一键式软件发布
3. 如何实现目标
为保证能持续的以高质量交付我们的软件，需要频繁的自动化发布软件
对于频繁的自动化发布软件，反馈是至关重要的，对于反馈，应该达到三个标准
- 无论什么样的修改都应该触发反馈流程（就像神经系统一样，时刻监控人的动态）
- 反馈应该尽快发出（被开水烫了，马上知道疼）
- 交付团队必须接收反馈，并依据它做出行动响应（疼了你得躲啊。。。）
下面详细介绍一下这三个标准
3.1. 无论什么样的修改都应该触发反馈流程
这些修改包括对以下项的修改
反馈流程
完全自动化的方式尽可能的测试每一次变更
测试内容包括但不限于
- 创建可执行代码的流程必须是能奏效的。这用于验证源代码是否符合语法
- 软件的单元测试必须是成功的。这可以检查应用程序的行为是否与期望相同
- 软件应该满足一定的质量标准，比如测试覆盖率以及其他与技术相关的度量项
- 软件的功能验收测试必须是成功的。这可以检查应用是否满足业务验收条件，交付了所期望的业务价值
- 软件的非功能测试必须是成功的。这可以检查应用程序是否满足用户对性能、有效性、安全性等方面的要求
- 软件必须通过了探索性测试，并给客户以及部分用户做过演示。这些通常在一个手工测试环境上完成。此时，产品负责人可能认为软件功能还有缺失，我们自己也可能发现需要修复的缺陷，还要为其写自动化测试来避免回归测试
3.2. 反馈应该尽快发出
关键是自动化，主要通过部署流水线来实现，后面各章会详细介绍
3.3. 交付团队必须接收反馈，并依据它做出行动响应
没有响应，反馈何用？
3.4. 这个流程可以推广吗
很多思想来源于精益制造，目标是快速交付高质量的产品，聚焦于消除浪费，减少成本
4. 收效
4.1. 授权团队
让整个团队合作在一起
4.2. 较少错误
通过减少手工的重复任务，避免大部分错误
4.3. 缓解压力
让发布任务变得简单可控，免得每次发布都如临大敌
4.4. 部署的灵活性
随时找到以往的部署版本，意见部署任意版本
4.5. 多加练习，使其完美
目标是不管部署到什么环境，都使用相同的部署方法
5. 候选发布版本
每次提交代码都产生一个可发布版本
但是实际开发中，要想验证一个可发布版本，就要进行一次集成，通常这个过程难以控制，所以就会推迟，集成频率越低，越痛苦，但是越痛苦的事，越要频繁去做，要么会更痛苦
本书会通过持续集成这一实践来让集成变得无痛
6. 软件交付的原则
为了保证高质量的持续交付，下面的可以当做行为准则了
6.1. 为软件的发布创建一个可重复且可靠的过程
归根结底，软件的部署包括三件事
- 提供并管理软件所需要的运行环境，包括硬件配置，所依赖的软件，基础设施以及所需的外部服务
- 将应用程序的正确版本安装其上
- 配置应用程序，包括所需的任何数据和状态
6.2. 将几乎所有的事情自动化
能让机器去做的就别自己做了
6.3. 把所有的东西都纳入版本控制
使每个版本相关的信息都能很快找到
6.4. 提前并频繁的做让你感到痛苦的事
这是一条很有用的启发式原则，更多解释可以看看《少有人走的路》
6.5. 内建质量
每个人都对质量负责，有问题立马解决
6.6. “DONE”意味着“已发布”
我们认为一个特性只有交到用户手中才算DONE，而不是开发完了就OK了
6.7. 交付过程是每个成员的责任
从相互指责扯皮到共同协作
6.8. 持续改进
戴明环（plan->do->check->act）
7. 小结
本书的目标是让发布过程变得无痛
新开了公众号，欢迎关注，主要分享一些读书笔记
