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