《持续交付-发布可靠软件的系统方法》，部分读书笔记。
为软件发布创建一个可重复且可靠的过程
让软件发布成为一件容易的事情，这是在你开始写一个软件开始前就要想办法达到的目标。只要软件发布简单到点击一个按钮甚至不需要点击按钮就能发布，你才会有动力去持续完善这个软件。
所以一般我在开始开发一个软件时就会考虑它的部署过程，会用到哪些资源，如果更新版本等等问题。
将几乎所有事情都自动化
有些工作是不能自动化的，比如分析业务逻辑，设计软件结构，编写测试等等。
但是能自动化的就尽可能让计算机来帮助你完成，比如发布软件涉及的各个环节，运行自动化测试，生成各种报告和指标。
重复的事情计算机往往比人更可靠，有时候你觉得它花的时间更多，但是它不用睡觉，你不行。
把所有东西都纳入版本控制
人都是健忘的，我们除了需要把代码纳入版本控制系统，应该还将跟项目有关的其他东西也纳入版本管理：
- 需求文档，测试用例，自动化测试脚本
- 机器配置，网络配置， 部署脚本
- 数据库创建，升级，回滚脚本等等
- 依赖配置，库文件，工具链，参考文档等等
要具体到当前发布的是哪个版本，用了哪些对应版本号的依赖和库，当时的需求和测试时什么样子的。
提前并频繁做让你感到痛苦的事情
这是最通用的原则，也是最有启发性的。可以说我们说的一切都可以归结到这一点上。反复做痛苦的事情会有两种可能的结果：
- 你麻木不仁了，周而复始继续痛苦
- 你揭竿而起了，把这个痛苦干掉了
提前并频繁去做，我相信你会选择第二种结果。
内建质量
“内建质量”是精益运动的先驱戴明提出的名言之一。从而得出两个结论：
- 测试不是一个阶段，也不应该在开发结束后才开始。
- 测试不纯粹或者主要是测试人员的领域。
交付团队里的每个人都应该对产品的质量负责，所以在需求调研，分析，开发过程中其实已经对质量造成影响。只有保证每个环节的质量，才能确保整体的质量。
“Done”意味着“已发布”
经常听开发说需求终于做完（Done）了，但真的做完了吗？对于敏捷团队来说，“Done”意味着功能已经部署到生产环境了，已交付给用户了才算完成。
一件事情没有完成80%的说法，要么完成了，要么就是没完成。从这一原则得出一个有趣的推论，一个事情完成与否，并不是一个人能控制得了的，他需要所有人参与，包括开发，测试，运维，支持等等。
交付过程是每个成员的责任
无论项目成功还是失败，其结果都是属于这个团队的。但现实中开发总是把困难交给测试，测试又把困难交给运维，当问题出现时，人们会花费大量时间来修复，也会用同等时间来互相指责推卸责任。
为了更加快速且可靠地交付软件，我们应该鼓励所有参与整个过程的人进行更好的协作。
持续改进
软件的首次发布只是生命周期里的第一个阶段，随着不断演进，更多的发布和需求会接踵而来。所以你的交付过程也要随之不断演进。
召开回顾会议是一个很好的实践，反思过去一段时间内什么做的好，继续保持，做的不好，记录并改进。每个改进点都应该有一个人负责跟踪，确保能被执行，下一次会议向大家汇报结果。
自动化的开发，测试以及发布过程对交付软件的速度，质量和成本有着深远的影响。