《持续交付》笔记——第1章 软件交付的问题

作者：蓝白云

越来越发现总结是多么的重要，那怕是一两句话也行。因为在我以前看过的书像看电影一样，看过后感慨一方就忘了差不多了。希望从现在做起，把每看过的书按照章节做个笔记或小结一把记录下来，也当作是回忆吧。但愿自己能够坚持下来。

看完《持续交付——发布可靠软件的系统方法》第1章“软件交付的问题”，感觉译者乔梁翻译得非常棒，语句非常流畅。好了，言归正传，笔记开始：

１、持续交付的中心模式：部署流水线。简单地说部署流水线就是指一个应用程序从构建、部署、测试到发布整个过程的自动化实现。

２、常见的软件发布反模式（也就是现实中的问题点）：”１）手工部署软件;２）开发完成之后才向类生产环境部署;３）生产环境的手工配置管理;“

　　”直至开发完成之后才做测试的话，无疑会降低应用程序的质量。一旦将应用程序部署到了试运行环境，我们常常发现新的缺陷。遗憾的是，我们没有时间修复所有问题。“

３、改进方法：自动化和频繁做。打个比方，就像打仗一样，需要战争前线及时反馈战况，以便指挥部做好下一步计划。难怪米国军队称霸世界，可见自动化做的多么的好。再加上他们也是在世界各地频繁地打仗啊。可我们呢，唉！

　　“每次修改（个人补充：项目中所有文件、配置环境等）都应该触发反馈流程;　交付团队必须接收反馈并做出反应。”

　　“将几乎所有事情自动化。“　因为手工效率低下，且容易出错。例如：手工测试某项目一次可以，第二次还行，第三次就会吐了，且几次下来时间成本也是相对高了。这些就让机器为我们服务吧。特别提到是软件部署也是可以自动化的。

　　”把所有的东西（例如：需求文档、测试脚本、自动化测试用例、网络配置脚本、部署脚本、技术文档等）纳入版本控制。“　要让刚加入的新成员在一台新电脑前，直接从版本库中Checkout项目所需的所有资料，并且能一键式构建、部署、测试和发布成功。当然这是理想化的，反问自己我们大家都不是朝着理想化而努力吗？个人认为确实必须要做到这一点。

　　我们自己常常也有这种心理：如果觉得有些事情太困难了，做起来比较痛苦，认为先可以放一放再说。那么”提前并频繁地做让你感到痛苦的事“一节很好地诠释了这种心理。例如，如果我们感觉到测试是一种痛苦的事情，那么就别在开发之后做，应从项目一开始就不断地进行测试。

　　”Done意味着已发布“，”根本就没有‘已经完成了80%'这一说法。任何事情要么是完成了，要么就是没完成。“，”一件事的完成与否，并不是一个能控制得了的，它需要整个交付团队共同来完成。“

　　”交付过程是每个成员的责任“

小结：

该章的精髓就是提倡自动化和频繁地反馈和做，又好比建房子时建筑工人需要利用垂直线一点点不断地修正墙体，才能建出高质量的房屋，否则可想而知。