序言：2014年去上海参加TW的一次持续交付大会，然后有幸在这次大会上被抽中为获奖的观众，不仅免费听了知识，还获得了《持续交付》这本书，当时囫囵吞枣的把这本书翻了翻，没有认真去读取体会，这段时间重读这本书，还有很多收获。
持续交付的问题
本书的中心模式是部署流水线，从本质上说部署流水线就是指一个应用程序从构建、部署、测试到发布这整个过程的自动化实现（和当前DevOps理念其实有很多重合的部分）。核心是自动化。而为了对构建和交付质量输出的验证和快速实现，测试的自动化也是关键，为了达到自动化，一些标准化的工作需要作为基础。
部署流水线的目标有三个：
首先，它让软件构建、部署、测试和发布过程可视化，促进沟通协作。
其次，快速反馈，持续集成要达到快速失败的目的，快速失败就是为了增强反馈的效率。
最后，使团队能够通过一个完全自动化的过程在任意环境上部署和发布软件的任意版本。
这里是书上说的三个目标，也是其价值，我这边还有一个补充，因为打通和串联了多个环节，促进了团队对质量责任的全局理念，打破了研发流程多个环节的壁垒。
常见的发布反模式（自我对照的镜子）：
1、手工部署软件
PS：过于复杂的脚本同样会带来一些问题，对于持续构建和持续交付的各环节，我也是提倡，脚本尽量是原子动作,一个脚本制作一件事，脚本中融合太多的逻辑会数据丢失，不能够沉淀下有价值的数据。大家也需要切记。
2、开发完成之后猜想类生成环境部署
绝大多数时候，部署都是一个大的事件，都会遇到一些问题，就想持续集成和敏捷教导我们的，越是容易出问题的地方，越要频繁做。
3、生产环境的手工配置管理
越多的依赖手工动作越容易出问题。尽量多的标准化，自动化。
是否能够做的更好，是否能够实现目标？
目标（快速、高效、可靠的方式交付高质量且有价值的软件）
我们要自动化（快速和高效的基础），要频繁的做（快速的反馈 ，降低版本交付范围，提高质量）
如何快速反馈？
1、每次修改都应该触发反馈流程
2、必须尽快接收反馈
3、团队必须对失败和反馈快速做出反应（第一优先级解决反馈问题）
其中有一点，作为灾难恢复手段，运维人员可以自己选择一个一直的正确版本，将其部署到生产环境。这里的版本，交付的版本必须进行管理和环节的拆分，对于研发的开发和测试欢迎也一样，必须要做到版本交付环节的独立拆分，使得用户可以独立的选择要部署的交付版本，在设计持续集成和DevOps类的平台要注意。
每次提交代码都可能产生一个可发布的版本
这个原则看似简单，但在实际的工作中会非常麻烦，比如svn这种版本控制卡，有时提交可能会遗漏到时不是一个事务的原子任务，就算是git有一个本地提交，很多任务会出现跨git仓库的情况，想要保证这一点还是有不少技术和工程实践上的问题。
软件交付的原则：
1、为软件的发布过程创建一个可重复且可靠的过程，为了达到这个目标，尽快能的自动化一切，把一切都纳入到版本控制系统中
2、将几乎所有事情都自动化
3、把所有的东西都纳入版本控制
4、提前并频繁地做让你感到痛苦的事
5、内建质量，测试是主要的关注点，而且要明确测试不是一个角色不是一个阶段，测试已经内嵌到研发流程的各个环节，并成为研发流程各环节各人员的都需要持续关注和投入的工作。
6、DONE 意味着已发布
7、交付过程是每个成员的责任
8、持续改进，戴明环，计划-执行-检查-处理（PDCA）