软件交付的原则
Post

软件交付的原则

《持续交付-发布可靠软件的系统方法》,部分读书笔记。

为软件发布创建一个可重复且可靠的过程

让软件发布成为一件容易的事情,这是在你开始写一个软件开始前就要想办法达到的目标。只要软件发布简单到点击一个按钮甚至不需要点击按钮就能发布,你才会有动力去持续完善这个软件。

所以一般我在开始开发一个软件时就会考虑它的部署过程,会用到哪些资源,如果更新版本等等问题。

将几乎所有事情都自动化

有些工作是不能自动化的,比如分析业务逻辑,设计软件结构,编写测试等等。

但是能自动化的就尽可能让计算机来帮助你完成,比如发布软件涉及的各个环节,运行自动化测试,生成各种报告和指标。

重复的事情计算机往往比人更可靠,有时候你觉得它花的时间更多,但是它不用睡觉,你不行。

把所有东西都纳入版本控制

人都是健忘的,我们除了需要把代码纳入版本控制系统,应该还将跟项目有关的其他东西也纳入版本管理:

  • 需求文档,测试用例,自动化测试脚本
  • 机器配置,网络配置, 部署脚本
  • 数据库创建,升级,回滚脚本等等
  • 依赖配置,库文件,工具链,参考文档等等

要具体到当前发布的是哪个版本,用了哪些对应版本号的依赖和库,当时的需求和测试时什么样子的。

提前并频繁做让你感到痛苦的事情

这是最通用的原则,也是最有启发性的。可以说我们说的一切都可以归结到这一点上。反复做痛苦的事情会有两种可能的结果:

  1. 你麻木不仁了,周而复始继续痛苦
  2. 你揭竿而起了,把这个痛苦干掉了

提前并频繁去做,我相信你会选择第二种结果。

内建质量

“内建质量”是精益运动的先驱戴明提出的名言之一。从而得出两个结论:

  • 测试不是一个阶段,也不应该在开发结束后才开始。
  • 测试不纯粹或者主要是测试人员的领域。

交付团队里的每个人都应该对产品的质量负责,所以在需求调研,分析,开发过程中其实已经对质量造成影响。只有保证每个环节的质量,才能确保整体的质量。

“Done”意味着“已发布”

经常听开发说需求终于做完(Done)了,但真的做完了吗?对于敏捷团队来说,“Done”意味着功能已经部署到生产环境了,已交付给用户了才算完成。

一件事情没有完成80%的说法,要么完成了,要么就是没完成。从这一原则得出一个有趣的推论,一个事情完成与否,并不是一个人能控制得了的,他需要所有人参与,包括开发,测试,运维,支持等等。

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

无论项目成功还是失败,其结果都是属于这个团队的。但现实中开发总是把困难交给测试,测试又把困难交给运维,当问题出现时,人们会花费大量时间来修复,也会用同等时间来互相指责推卸责任。

为了更加快速且可靠地交付软件,我们应该鼓励所有参与整个过程的人进行更好的协作。

持续改进

软件的首次发布只是生命周期里的第一个阶段,随着不断演进,更多的发布和需求会接踵而来。所以你的交付过程也要随之不断演进。

召开回顾会议是一个很好的实践,反思过去一段时间内什么做的好,继续保持,做的不好,记录并改进。每个改进点都应该有一个人负责跟踪,确保能被执行,下一次会议向大家汇报结果。

自动化的开发,测试以及发布过程对交付软件的速度,质量和成本有着深远的影响。

使用VueJS开发油猴(TamperMonkey)脚本

微不足道的改进