低风险发布,再读《持续交付2.0(增订版)》
两年前看了乔梁编写的《持续交付2.0》,收获颇多,还写了一篇读书笔记,今年 2 月,该书出了增订本,增加了一个章节的内容,其他的一些章节内容也有局部的优化。
花了一个多星期,翻阅了这本增定本,就像在之前读书笔记中说的,好书是常读常新的,每次都会带来新的收获和思考,取决于你当下的认知和期望能解决的问题。
新增的第 17 章主要在讲研发组织的效能提升,从软件的复杂度,谈到了产品研发的胜任力模型到最后的组织健康度,在一个比较抽象的层面给我们打开了思路,因为篇幅的原因,没有展开讲。
相比新增的章节,我重新看的过程中发现低风险发布是我最感兴趣的,我们现在的产品正在进行 SaaS 化改造,上线后就会面临着持续发布的问题,这里面的内容正好用得上。
下面说几个我们遇到的问题以及按照书中的思路应该怎么去解决:
1、发布上线,怎样保证稳定性?
通常我们发布上线,就是停机发布,发布后,所有的人看到的都是最新的版本。这样其实风险是比较高的,风险有两个方面,一是生产环境和测试环境总会有些差异,有时在测试环境没有问题到生产会出现问题;二是程序上有缺陷会影响到所有的用户。
下面有几种低风险的发布方式:
蓝绿部署:
假设现在有一个生产环境 A,再准备一套和这个生产环境完全一致的环境 B,其中 A 对外提供服务,B 作为预发布环境。
发布时,发布到 B 环境,可以在这个环境上做一些测试验证,没有问题后,将 B 对外提供服务,A 作为下一次的预发布环境,如此循环。
这种方式有个问题就是需要考虑到数据库,如果两个环境使用一个数据库,就需要处理两个不同版本的兼容性问题;如果每个环境都有自己的数据库,那么在两个环境进行切换时,可能会存在数据不一致的问题。
灰度发布:
一个新功能上线,让一部分人先使用,然后陆续开放给所有用户。如有问题,只会影响到一小部分用户。
很多互联网公司采用这种方式来验证一个新的功能是否受欢迎。微信发布新功能,很多时候也是采用灰度的方式。
在部署时,可以先只更新其中的某些节点,那么负载到这些节点的用户看到的就是新的内容,其他节点的还是之前的内容,至于谁能看到这些新的内容,在网关层可以根据 IP、区域、特定用户等来进行负载,具体看业务场景了。
滚动发布:
一个集群中有很多个节点,选择其中一个停止服务,进行更新,更新完后将其投入使用,依次将所有的节点更新完。
我们现在有一个客户每次升级就是采用这种方式,对用户来说几乎是无感知的,因为一个节点在进行升级的时候,其他的节点依然能够提供服务。
但有一个点需要注意,就是如果版本更新较大涉及到了数据库结构的改动,需要做兼容性处理。
2、产品进行大规模的重构时,常规功能怎样同时进行?
去年我们就经历过一次比较大的重构,主要做了很多的代码结构的调整,提升程序的性能,而在这个期间,几乎没有做常规功能的迭代,我们的做法就是以当前发布分支拉取一个优化分支进行代码修改,发布分支上只做些 Bug 修复,修复完后就及时合并到优化分支,最后优化完成,再合并到发布分支。
而我们想要的是一边做常规功能,一边进行优化。
首先分析进行重构的部分是不是能够进行拆解,如果能够拆分成一些小的独立的部分,就可以安排在迭代内完成并和常规功能一起发布上线。
很多时候,重构优化涉及的模块非常多,这时就可以引入中间层,加上开关控制,新的逻辑和老的逻辑同时存在,逐步替换,等到所有的都替换完后,再将老的逻辑删除。
唯一不足的就是重构的周期会比较长。
3、在一个迭代周期内,前后端的任务总是不能吻合地很好,应该怎么办?
这里说的吻合是指在一个迭代中前端和后端的任务量相当,同时结束工作,同时开始下一迭代。以我们这半年实践敏捷开发发现,这种理想状况很难。
我们现在的模式是三周迭代,以目前的能力无法做到每个开发人员的任务安排到最后一天,因为最后几天测试人员要进行整体回归测试。这就存在一个衔接的问题,开发人员在当前迭代的任务结束了,但迭代周期没有结束,那么开发人员应该做什么?
关于这个问题,我跟领导沟通过很多次,最近也咨询了一家大公司的产品团队负责人,再加上本书中的讲解,我大致总结了下:
- 在敏捷团队中,所有人都是为了一个迭代目标而努力,去冲刺;
- 在一个迭代中,开发人员的开发任务完成了,可以参与测试、进行后续任务的技术验证、或者一些非功能性需求的实现(代码优化、扩展性、可读性、性能等);
- 一个迭代中的任务保证前端都是可以测试和交付,但后端人员如果有空闲,可以多安排后端任务,发布后,因为没有操作入口,也不会产生影响;
- 尽可能在一个迭代周期内完成能发布的功能,如果有些不能发布,通过开关来进行控制。
这是第二次读这本书,但我相信不会是最后一次。