一 什么是持续交付
持续交付是一种开发实践，即频繁地将软件的最新版本交付给测试或者用户进行验证，如果验证通过，代码就可以随时部署到线上。
持续交付的中心模式是部署流水线，即将一个应用程序从构建、部署、测试到发布整个过程的自动化。部署流水线的三个目标：
- 让软件构建，部署，测试和发布过程对所有人可见，促进合作
- 改善反馈，及早的发现并解决出现的问题
- 使在任何环境下部署和发布任意版本的应用
二 开发中常见的反发布模式
1 手工部署软件
先来看看手工部署软件的一些常见的特征：
- 有一份详情的操作文档，其中包含一些注意事项
- 必须要手工测试程序是否正确运行
- 发布结果无法预测
- 经常加班，而且还可能解决不了问题
- 可能会有用户来问部署又出问题了
很显然，目前很多公司都没能去很好的重视自动化的测试、部署，他们一般都会认为去做这些会浪费很多时间，从而导致了在开发过程中遇到很多的不可预测的问题，在遇到这些问题时又不得不去花大量的精力去排查并修复。
而正确的流程应该是按一下部署按钮就可以进行部署，这样做的好处也是很明显的：
- 使得部署过程更加简单，可复用
- 不用再去维护部署文档
- 摆脱对人的依赖（部署专家）
2 开发完之后才向生产环境部署
这对于维护人员无疑是一个噩梦。当开发完才第一次向生产环境去部署的话，可能导致很多不可预测的问题，比如：开发环境和生产环环境的差异、各种配置文件没能在生产环境中去测试 ...
正确的部署姿势应该是开发环境和生产环境应该尽量的保持一致，使得在生产环境上随时可以发布最新的版本。
3 生产环境的手工配置
自己在实习十也遇到了这类的问题，就是自己在本地跑的好好的，然后到生产环境上有的时候就出现了问题，而问题的产生就是有些配置文件的不统一而造成的。书中提到了将配置文件也进行统一的管理，对于配置的修改应该是自动化的，不应该是人为的手动修改。
对于上述的几种反发布模式我们应该是禁止采用的，我们应该采用部署流水线的方式，即找到一种高效、快速、可靠的方式交付高质量的软件，并实现自动化的测试和部署，以及全面的配置管理结合在一起，实现一键式软件发布
三 如何实现目标
为了实现我们的目标，即持续的交付高质量的软件，我们必须要做到频繁的自动化发布软件，这也就意味着频繁的反馈，反馈应该具备以下几个标准：
1 无论什么样的修改都应该触发反馈流程
这些修改包含了以下的修改：
- 对源代码的修改（CI）
- 对配置信息的修改（配置管理）
- 对运行环境的修改（环境管理）
- 对数据的修改（数据管理）
当出现这些修改时，我们的自动化测试应该被立刻执行，而这些测试包括：
- 创建可执行代码的流程必须是能奏效的。这用于验证源代码是否符合语法
- 软件的单元测试必须是成功的。这可以检查应用程序的行为是否与期望相同
- 软件应该满足一定的质量标准，比如测试覆盖率以及其他与技术相关的度量项
- 软件的功能验收测试必须是成功的。这可以检查应用是否满足业务验收条件，交付了所期望的业务价值
- 软件的非功能测试必须是成功的。这可以检查应用程序是否满足用户对性能、有效性、安全性等方面的要求
- 软件必须通过了探索性测试，并给客户以及部分用户做过演示。这些通常在一个手工测试环境上完成。此时，产品负责人可能认为软件功能还有缺失，我们自己也可能发现需要修复的缺陷，还要为其写自动化测试来避免回归测试
** 2 反馈应该尽快发出**
关键还是在于自动化而非手工。
** 3 交付团队必须接收反馈，并依据它做出行动响应**
4 这个流程可以推广吗
四 软件交付的原则
1 为软件的发布创建一个可重复且可靠的过程
2 将几乎所有的事情自动化
3 把所有的东西都纳入版本控制
4 提前并频繁的做让你感到痛苦的事
5 内建质量
6 “DONE”意味着“已发布”
7 交付过程是每个成员的责任
8 持续改进(戴明环：PDCA)
几个概念的解释：
- 内建质量： 团队中每个人都对质量负责，有问题立马解决，越早发现缺陷，修复它们的成本越低。
- 戴明环：是一个持续改进模型， 它包括持续改进与不断学习的四个循环反复的步骤， 即计划（Plan）、执行（Do）、检查（Check/Study）、处理（Act）
- 对数据的修改，其中数据的修改指的是数据库中的数据的更改、数据表结构的更改、文件中的数据等
