原文链接 http://veryyoung.me/blog/2016/11/21/continuous-delivery-reading-note.html
注：以下为加速网络访问所做的原文缓存，经过重新格式化，可能存在格式方面的问题，或偶有遗漏信息，请以原文为准。
上篇写到了持续集成，其实持续集成只是持续交付中的一个环节而已。
那么什么是持续交付呢？
下面是我读《持续交付》的读书笔记。
<!-- more -->
什么是持续交付？
持续交付是一种开发实践，指的是，频繁地将软件的新版本，交付给 QA 或者用户进行验证，如果验证通过，代码就可以随时部署到线上。
持续交付在持续集成的基础上，将集成后的可执行文件到更贴近真实运行环境的中。持续交付建立在高水平自动化持续集成之上。
持续交付的好处
减少错误
自动化的交付可以避免很多手工操作引起的失误，可以防止配置不一致引起部署问题。
尽早暴露问题
如果有代码错误，或配置项错误，或潜在的 bug，在 build、自动化测试 和 UAT 过程中被早早的发现，避免上线酿成大错。
缓解压力
发布软件是非常有压力的，RD 同学应该感触非常深刻。
做到持续交付，上线就变成点个按钮的事情，几秒过后，代码就成功上线了，不再是惊心动魄。
就算很不幸的部署失败了，也可以通过一个按钮飞速的回滚到上一个可用的版本。
做到这些之后，上线还有压力吗？
进度可控
传统的软件开发，都是在上线前才开始 build，打包，配置环境，部署。在这之前，项目经理、客户根本没法知道软件开发的进度如何，甚至 开发人员都不太信心。
持续交付的流程
下图是 CD 的大概流程
- 提交代码，自动执行构建。
- 构建完毕，自动执行自动化测试。
- 自动化测试执行完，自动部署环境到 staging。
- QA 或者 UAT 验收完之后，手工部署到线上。
持续交付的原则
1.为软件发布创建一个可重复且可靠的过程
这个原则能达到的目标是：让软件发布成为一件非常容易的事情。
事实上，如果做到了持续交付，这确实是一件很容易的事情。因为在发布之前，发布的每个流程都测试了无数遍。 而发布本身则变成了一个点击按钮一样简单的事情。
这种可重复性和可靠性来自两个原则：
- 几乎将所有事情自动化。
- 将构建、部署、测试和发布所需要的所有东西全部纳入版本控制。
2.将几乎所有事情自动化
构建应是自动化的，测试应是自动化的，数据库的升级应是自动化的，配置选项也应该是自动化的，验收测试也要尽可能做到自动化，尽管成本非常高。
有些工作是无法手工化的，比如判断 UI 美不美，探索软件的交互合不合理。但能自动化的应该尽量自动化。
3.把所有东西纳入版本控制
把所有东西纳入版本控制，包括数据库 schema，初始化数据，部署脚本，测试用例，测试脚本，程序所依赖的配置项等。
只有做到这个，可以快速搭建起持续集成工具，而且一个新入职的同学也能依赖这些东西快速 set up 起开发环境。
4.持续集成
这个在上篇文章 《持续集成》读书笔记 已经说过了。
5.“DONE” 意味着已发布
DONE 意味着已部署在线上，而不是”代码已经写完了“。
6.交付是每个人的责任
团队成员应有共同目标，那就是交付产品。开发人员需要为交付产品来提供一些规范和手段，PM、QA 等人员也需要关注交付的进度和状态。
7.持续改进
随着程序的迭代，交付过程也需要不断的演进。在交付可能出现问题之前，团队应该聚集在一起，讨论下哪个地方需要改进，提出方案并实施。
配置管理
配置管理往往可以看做版本控制的同义词，配置管理是一个过程，通过该过程，所有与项目相关的产物以及他们之间的关系都被唯一定义、修改、存储和检索。 配置管理非常重要，很多工作都有配置管理这个职位，三言两语说不清楚。
配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。
总而言之，持续交付中的配置管理需要把所有东西都纳入版本控制。
持续集成
没有持续集成，就不会有只持续交付，关于持续集成这里就不展开说了，可以参考 《持续集成》读书笔记。
自动化测试
自动化测试是保证软件质量的一个比较通用的做法，可以使用 JUnit 这样的测试框架。
通过自动化测试，我们能满足客户快速变更的需求，而不至于把旧功能搞挂掉。 自动化测试使得每次构建（即使只是微小变动）都是经过测试和验证的稳定版本。
部署流水线（Pipeline）
从构建流水线图中我们可以看到，持续集成服务器是在不断监视着源代码库的变化，一旦有人提交就会触发构建过程，如果其中发生问题，则会将结果反馈给团队。
如果构建成功，则进入自动化验收测试。
如果自动化验收测试通过，则自动把程序部署到 staging 环境，进行 UAT 测试，UAT 能通过就能马上上线啦。