持续交付（第一章）—软件交付的问题
从今天开始阅读《持续交付》，相信这本书会对我以后的软件开发起到很大的帮助，在之前的团队合作时，也有遇到很多关于部署协作方面的问题，确信这本书可以解决我之前的一些疑惑。
持续集成
在这一章中，作者向我们介绍了一些在软件开发过程中常见错误方式，并提出了改善方法。从整体上向我们介绍了本书的主旨以及应该采用的方法。
常见的反模式发布模式
1.手工部署软件
对于现在的大多数应用程序来说，无论规模大小，其部署过程都是比较复杂，而且包含很多灵活的部分。许多团队现在仍然使用手工方式发布软件，每个步骤里都有一些需要人为判断的事情，因此很容易发生人为错误。
2.开发完成之后才向类生产环境部署
这样会导致许多原来看不到的问题一下子出现，开发团队和真正执行部署任务的人员协作非常少，而且可能会为了按时交付软件，匆忙修复一些问题，这样就为之后的完善埋下了错误的种子。
3.生产环境的手工配置管理
这样由专人进行手工配置，可能会导致部署生产环境失败，系统无法回滚到之前部署的某个配置。
如何进行完善
有两个方法可以帮助到我们高效，快速，可靠的交付高质量有价值的软件方法。
1.自动化
如果构建，部署，测试和发布流程不是自动化的，那它就是不可重复的，由于软件本身，系统配置，环境以及发布过程的不同，每次做完这些活动以后，其结果可能都有所不同，由于每个步骤都是手工操作，所以出错的机会很大，而且无法确切地知道具体都做了什么。这意味着整个发布过程无法得到应有的控制来确保高质量。
2.频繁做
如果能够做到频繁发布，每个发布版本之间的差异会很小，这会大大减少与发布相关的风险，且更容易回滚。频繁发布也会加快反馈速度，而客户也需要它。
软件交付的原则
1.为软件的发布创建一个可重复且可靠的过程
这种可靠性和重复性来自两个原则，一个是几乎将所有事情自动化，另一个就是将构建，部署，测试和发布软件所需的东西全部纳入到版本控制管理当中。
2.将几乎所有事情自动化
自动化是部署流水线的前提条件，因为只有通过自动化才能让大家仅仅通过单击按钮就能看到他们想要的。
3.把所有的东西都纳入到版本控制
4.提前并频繁地做让你感到痛苦的事
5.内建质量
6.“DONE”意味着“已发布”
7.交付过程是每个成员的责任
8.持续改进
总结&思考
在看这一章中，有收获也有疑惑，我的收获就是：
- 尽可能多的为我的代码写测试，覆盖率要尽量高。
- 将所有有关项目的东西都纳入到版本管理工具中，比如github
- 频繁提交，小步快走
- 项目尽可能的实现自动化
我的疑惑： - 怎么为配置环境写测试，并纳入版本管理中
- 所有东西都要纳入版本管理中么？包括一些文本文档么？
- 自动化的工具都有哪些？
- 前端测试框架可以实现白盒测试么？
