低风险发布，再读《持续交付2.0（增订版）》

两年前看了乔梁编写的《持续交付2.0》，收获颇多，还写了一篇读书笔记，今年 2 月，该书出了增订本，增加了一个章节的内容，其他的一些章节内容也有局部的优化。

花了一个多星期，翻阅了这本增定本，就像在之前读书笔记中说的，好书是常读常新的，每次都会带来新的收获和思考，取决于你当下的认知和期望能解决的问题。

新增的第 17 章主要在讲研发组织的效能提升，从软件的复杂度，谈到了产品研发的胜任力模型到最后的组织健康度，在一个比较抽象的层面给我们打开了思路，因为篇幅的原因，没有展开讲。

相比新增的章节，我重新看的过程中发现低风险发布是我最感兴趣的，我们现在的产品正在进行 SaaS 化改造，上线后就会面临着持续发布的问题，这里面的内容正好用得上。

下面说几个我们遇到的问题以及按照书中的思路应该怎么去解决：

1、发布上线，怎样保证稳定性？

通常我们发布上线，就是停机发布，发布后，所有的人看到的都是最新的版本。这样其实风险是比较高的，风险有两个方面，一是生产环境和测试环境总会有些差异，有时在测试环境没有问题到生产会出现问题；二是程序上有缺陷会影响到所有的用户。

下面有几种低风险的发布方式：

蓝绿部署：

假设现在有一个生产环境 A，再准备一套和这个生产环境完全一致的环境 B，其中 A 对外提供服务，B 作为预发布环境。

发布时，发布到 B 环境，可以在这个环境上做一些测试验证，没有问题后，将 B 对外提供服务，A 作为下一次的预发布环境，如此循环。

这种方式有个问题就是需要考虑到数据库，如果两个环境使用一个数据库，就需要处理两个不同版本的兼容性问题；如果每个环境都有自己的数据库，那么在两个环境进行切换时，可能会存在数据不一致的问题。

灰度发布：

一个新功能上线，让一部分人先使用，然后陆续开放给所有用户。如有问题，只会影响到一小部分用户。

很多互联网公司采用这种方式来验证一个新的功能是否受欢迎。微信发布新功能，很多时候也是采用灰度的方式。

在部署时，可以先只更新其中的某些节点，那么负载到这些节点的用户看到的就是新的内容，其他节点的还是之前的内容，至于谁能看到这些新的内容，在网关层可以根据 IP、区域、特定用户等来进行负载，具体看业务场景了。

滚动发布：

一个集群中有很多个节点，选择其中一个停止服务，进行更新，更新完后将其投入使用，依次将所有的节点更新完。

我们现在有一个客户每次升级就是采用这种方式，对用户来说几乎是无感知的，因为一个节点在进行升级的时候，其他的节点依然能够提供服务。

但有一个点需要注意，就是如果版本更新较大涉及到了数据库结构的改动，需要做兼容性处理。

2、产品进行大规模的重构时，常规功能怎样同时进行？

去年我们就经历过一次比较大的重构，主要做了很多的代码结构的调整，提升程序的性能，而在这个期间，几乎没有做常规功能的迭代，我们的做法就是以当前发布分支拉取一个优化分支进行代码修改，发布分支上只做些 Bug 修复，修复完后就及时合并到优化分支，最后优化完成，再合并到发布分支。

而我们想要的是一边做常规功能，一边进行优化。

首先分析进行重构的部分是不是能够进行拆解，如果能够拆分成一些小的独立的部分，就可以安排在迭代内完成并和常规功能一起发布上线。

很多时候，重构优化涉及的模块非常多，这时就可以引入中间层，加上开关控制，新的逻辑和老的逻辑同时存在，逐步替换，等到所有的都替换完后，再将老的逻辑删除。

唯一不足的就是重构的周期会比较长。

3、在一个迭代周期内，前后端的任务总是不能吻合地很好，应该怎么办？

这里说的吻合是指在一个迭代中前端和后端的任务量相当，同时结束工作，同时开始下一迭代。以我们这半年实践敏捷开发发现，这种理想状况很难。

我们现在的模式是三周迭代，以目前的能力无法做到每个开发人员的任务安排到最后一天，因为最后几天测试人员要进行整体回归测试。这就存在一个衔接的问题，开发人员在当前迭代的任务结束了，但迭代周期没有结束，那么开发人员应该做什么？

关于这个问题，我跟领导沟通过很多次，最近也咨询了一家大公司的产品团队负责人，再加上本书中的讲解，我大致总结了下：

• 在敏捷团队中，所有人都是为了一个迭代目标而努力，去冲刺；
• 在一个迭代中，开发人员的开发任务完成了，可以参与测试、进行后续任务的技术验证、或者一些非功能性需求的实现（代码优化、扩展性、可读性、性能等）；
• 一个迭代中的任务保证前端都是可以测试和交付，但后端人员如果有空闲，可以多安排后端任务，发布后，因为没有操作入口，也不会产生影响；
• 尽可能在一个迭代周期内完成能发布的功能，如果有些不能发布，通过开关来进行控制。

这是第二次读这本书，但我相信不会是最后一次。