《持续交付》——第一章--软件交付的问题

部署流水线

指一个应用程序从构建，部署，测试到发布整个过程的 自动化 实现

部署流水线的目标

• 让软件从构建，部署，测试到发布整个过程对所有人可见，促进合作
• 改善了反馈，让我们能及早的发现并解决问题
• 能够让一个团队通过完全自动化的过程在任意环境上部署和发布软件的任意版本

常见的发布反模式：

• 手工部署软件
  由个人或者小组来分别实行，容易发生人为错误，依赖于部署专家，部署不可重复且不可靠，手工部署流程被写在文档里，但是一般文档不能及时更新，不易于理解

• 开发完成后向类生产环境中部署
  开发团队和执行部署任务的人员之间协作少，开发测试与运维人员交流成本大

• 生产环境的手工配置管理
  运维团队需要为每次发布准备环境，系统无法回滚到之前部署的某个配置

自动化部署的威力

自动化的测试和部署以及全面的配置管理结合在一起，可以实现一键式软件发布，使软件发布能够成为一个低风险，频繁，廉价，迅速且可预见的过程。就像是工业流水线上生产的零件一样，可以确保次的生产规格相同，而且这个过程可以不断重复。

频繁自动化发布软件的优点：

频繁发布软件，使得软件的各个版本差异较小，容易回滚，减少与发布相关的风险，交付团队可以及时得到反馈并作出应对

配置管理

减少错误：在版本控制库中尽可能的管理所有可能变动的内容，比如配置文件，创建数据库及其模式的脚本，构建脚本，测试工具，甚至开发环境和操作系统的配置。
我们的经验是依赖于手工配置，但是配置参数都由手工配置管理难免会出现人为错误，而且很少有那种检查防止能用于配置信息的验证。所以将配置信息放入版本控制系统中，如果你不小心修改了配置信息，系统会作出提醒，因为配置改动导致软件出现的问题难以查找。

持续集成

集成阶段是软件开发后期最不可预测，最不易管理的阶段，集成频率越低，集成时的工作越难开展。所以我们不能回避这个任务，解决它的最好办法就是频繁地去做，事实上应该每次提交修改后都做集成。持续集成会及时检测到任何一次破坏已有系统或者不满足客户验收测试的提交，坚持这个实践，软件会一直处于可用状态。
所以持续集成就是不断地将新的内容更新到可用软件中，并保证软件的可运行，每一个改动或增加都要在较短的时间内反映到软件中。

理想的状态

除了需要人为决定的事情外，其余所有的流程应该都是自动化的。比如验收测试，数据库的升级降级，甚至网络和防火墙的配置。
自动化发布流程就相当于一个工具，你去干砍柴，拿了一把斧头，如果你只是砍几颗树，那么这把斧头就足够用了，你完全不会考虑去很远的集市上弄一个电锯，但是要砍一片树林，无疑去弄个电锯才是明智的选择。况且自动化发布流程不会像电锯一样被损耗。

小结

提前做麻烦事，将让你觉得痛苦的事反复的做，将大麻烦化小，就像一团麻，每天整理一点也不至于到最后无从下手。
及时的反馈对于软件的开发至关重要，客户能够及时获得可运行的软件，并提出需要改进的点，开发团队可以及时获得反馈并作出改进。
软件交付需要每个成员拥有高度的责任感，及时沟通交流解决问题，而不是相互指责，遇到问题时客户最关心的是尽快解决问题，而不是追查责任人。

疑问

1. 现在常见的发布反模式：手工部署软件，开发完成后向类生产环境中部署，生产环境的手工配置管理，这些反模式都存在一定的不足，现在的软件开发中是根据具体实际的情况选择部署方式吗？具体在什么情况下选择哪种方式呢？
2. 配置管理：我们现在使用的GitHub能够管理配置信息吗？
3. 对于不同的软件来说部署流水线不同，怎么根据软件的规模来判断是否需要部署流水线？
4. 部署工具是对于一个软件特制的吗？
5. 对于软件发布的具体流程不是特别清楚。