一、软件交付过程中的反模式
-
手工部署软件
主要表现:具备详尽的部署文档、部署完成后需要手工测试验证程序是否正常运行、部署的时间比较长
缺点:人工部署的过程不受控,部署文档维护费力,过度依赖具体专职部署专家 -
开发完成后才像类生产环境部署
-
生产环境的配置需要手工管理等
二、持续交付的目的
让软件发布成为低风险、频繁、廉价、迅速且可预见的活动。
【精益思想】:聚焦于消除浪费、减少成本
【频繁发布的目的】:使得每个发布版本之间的差异变小,大大减小发布相关的风险,也可以加快反馈速度(指的是发布过程中的反馈)。
【反馈流程的含义】:以完全自动化的方式尽可能地测试每一次变更,包括以下检测:单元测试成功、满足质量标准(测试覆盖率等度量项)、验证测试成功、通过探索性测试
要建立快速反馈机制,对信息进行广播,让所有人员包括开发、测试、运维都要参与到这个反馈流程中
三、软件交付的原则
-
为软件的发布创建一个可重复且可靠的过程(具体表现为2、3两点)
-
将几乎所有的事情自动化,不包括探索性测试
-
把所有的东西都纳入版本控制,存入某个可控制版本的存储库中国,如GIT,包括需求文档、测试脚本、测试用例、配置升级回滚脚本等
-
提前并频繁地做让你感到痛苦的事情,即持续改进
这是一条启发式的原则,在持续改进的过程中要分配好时间,分目标进行改进直到不再痛苦 -
内建质量(尽早发现缺陷)
所有的原则都是为了尽早发现缺陷,因此交付团队必须执行铁一般的纪律,一旦发现缺陷,就要马上着手修复 -
DONE意味着已发布交付
对于某个功能或者用户故事,不是开发完成就算DONE了,而是交付给用户以后才算DONE -
交付过程是每个成员的责任
与DevOps运动的核心原则一致:为了更加快速且可靠地交付有价值的软件,鼓励所有参与软件交付整个过程中的人进行更好的协作。 -
持续改进
戴明环(PDCA):计划-执行-检查(回顾)-处理
【关键】关键在于组织的每个人都要参与整个过程,如果只是在自己角色的内部进行反馈环,而不是在整个团队范围内进行的话,就会产生一种顽疾:以整体优化为代价的局部优化,最终导致互相指责