在这一章中作者给我们介绍了软件交付中常见的发布问题和解决的方法，带我们走进了这本书的主旨和所采用的高效的开发方法。
一些常见的发布反模式
1.手工部署方式
对于现在的大多数应用程序来说，无论规模大小，其部署过程都比较复杂，而且包含很多非常灵活的部分，许多组织都使用手工式发布软件，每个步骤都有一些需要人为判断的事情，因此很容易发生人为的错误。
2.开发完成之后才向类生产环境部署
这样会导致很多之前看不到的问题一下子爆发出来，不良协作使得在试运行环境上的部署工作问题重重，我们会发现新的缺陷，但是常常没有时间修复所有的问题。，这样会为之后的发布埋下隐患。
3.生产环境的手工配置管理
这样由专人负责配置，不能实现重复的创建哪些你开发的应用程序所依赖的每个基础设施，在部署出错时，我们不能将系统回滚到之前的版本。
如何实现目标
目标：尽快地向用户交付有用的可工作的软件。
1.自动化
如果构建、部署、测试和发布流程不是自动化的，那它就是不可以重复的。由于软件本身、系统配置、环境以及发布过程的不同，每次做完这些活动以后，其结果可呢呢个都会有所不同。由于每个步骤都是手工操作，这意味着整个发布过程无法得到应有的控制来确保高质量。常常说软件发布像是一种艺术，但事实上，它应该是一种工程科学。
2.频繁做
如果能够做到频繁发布，每个版本之间的差异会很小。这会大大减少与发布相关的风险，且更容易回滚。频繁发布也会加快反馈速度，而客户也需要它。
软件交付的原则
1.为软件发布创建一个可重复且可靠的过程
这种可重复性和可靠性来自以下的两个原则：（1）几乎将所有事情自动化；（2）将构建、部署、测试和发布软件所需的东西全部纳入到版本控制管理中。
2.将几乎所有事情自动化
3.把所有的东西都纳入版本控制
将构建、部署、测试和发布的整个过程中所需的东西全部保存在某种形式的版本存储库中，包括需求文档、测试脚本、自动化测试用例等。
4.提前并频繁地做让你感到痛苦地事
5.内建质量
6.“DONE”意味着“已发布”
一个特性只有交到用户手中才能算“DONE”
7.交付过程是每个成员地责任
8.持续改进
我的收获&疑问
- 我们应该将老师之前所说的小步提交切实的使用在我们的项目中，这样我们可以做到频繁的提交有用的代码，使我们每次提交的版本之间的差异小，也有利于我们之后的回滚。
- 每次提交的代码都要进行测试，将测试运用在自己的项目的每个部分，提高测试的覆盖率，这样可以确保我们提交的代码是可执行的。
- 项目应尽可能的实现自动化的部署
- 环境配置的参数会对软件的执行产生影响
- 所有的配置信息都要放在版本控制系统中
疑问：
- 自动化的管理工具有哪些？
- 各种文档纳入版本控制有必要吗？
- 环境配置的内容都有哪些？
