前言
- 书名来源于敏捷宣言的第一原则：“我们的首要任务是尽早持续交付有价值的软件并让客户满意”。
- 本书的一个主要目标是改善负责软件交付相关人员之间的协作，尤其是开发人员，测试人员，系统和数据库管理人员以及经理。
- 本书的中心模式是流水线模式，本质上来说就是指一个应用程序的构建、部署、测试到发布这整个过程的自动化实现
常见的发布反模式
首先我们要知道为什么会出现反模式，这是由于软件发布时需要很多的手工操作，很容易出错。为了可靠的发布，避免一些错误。
下面是一些与可靠发布过程相对应的常见反模式。
-
手工部署软件
无论规模大小，部署的过程比较复杂，而且所需要的步骤时独立的原子操作，由团队或者个人执行，但很容易发生人为错误。而且还有部署顺序的不同导致的差异性。
-
开发完成之后才向类生产环境部署
软件第一次被部署到类生产环境时，是大部分工作完成时，或者开发团队认为“该软件开发完成了”。
这样做会出现很多的问题，由于部署工作的很多步骤根本没有在试运行环境上测试过，所以经常遇到问题。
对策：将测试，部署和发布也纳入到开发过程中。使用大量的持续集成和持续部署是我们所描述的方法的基石。
-
生产环境的手工配置管理
由专门的运维团队管理生产环境的配置，如果需要修改一些东西，就要登陆到生产服务器手工修改。
如何实现目标
作为软件从业者，目标是尽快的向用户交付有用的可工作的软件。
即要找到一种可以高效、快速、可靠的方式交付高质量且有价值的软件的方法。为了实现这些目标，我们需要频繁且自动化的发布软件。
- 对于频繁且自动化的发布，反馈很重要，下面关于反馈的三个标准。
- 每次修改都应该触发反馈流程
- 必须尽快接收反馈
- 交付团队必须接收反馈并作出反映
收效
前面的方法，最主要的是创建了一个发布流程（可靠的，可重复的，可预见的，缩短发布周期）
- 授权团队
使测试人员，运维人员，和支持服务的人员做到自服务，团队能够更好的进行工作，协作更有效。 - 减少错误
指的是由不良好的配置管理引入到生产环境的错误 - 缓解压力
- 部署的灵活性
候选发布版本
有两种存在差异的理解
- 代码的任何一次修改都有被发布出去的可能
-
维基百科
指可能成為最終产品的候选版本，如果未出現問題則可释出成为正式版本。在此階段的产品通常包含所有功能、或接近完整，亦不會出現严重问题。
软件交付的原则
- 为软件发布创建一个重复且可靠的过程
- 几乎将所有的事情自动化
- 把所有的东西纳入版本控制
- 提前并频繁的做让你感到痛苦的事
- 内建质量
- “DONE” 意味着 “已发布”
- 交付过程每个成员的责任
- 持续改进
问题
- 既然手工部署即复杂又费时费力，又有自动化的存在，那么手工方式到底有没有被替代。
- 怎样进行的部署？
- 配置管理（第二章）的内容不是很清晰，还有就是和我们平时的配置的内容有关系吗？配置管理是配置信息的管理？
- 候选发布版本的准确理解是哪一种？
总结
- 对软件交付的过程有了一个大致的了解，对于开发的过程有了一个大致的认识，与我们自己开发还是有很大的区别的
- 要尽可能的自动化，会减少很多的麻烦和不必要的错误
- 把所有的东西纳入版本控制中
- 团队合作在开发中十分重要，从开始要保证由各个成员参与到发布中，大家可以有机会频繁且有规律的进行交流。那么这个频繁的交流是怎样来确定的。
