在一个迭代中，产品的所有Bug都修复完毕后，就开始进入发布流程了，但产品发布是不是就简单地更新生产服务端、更新生产客户端就行了呢？别急，在上线前我们还要确保几个关键点达标才能发布，毕竟线上产品的质量取决于从产品设计、开发、测试、运维的各个环节，其中任何一个环节出错都有可能影响线上产品的质量，整个产品从设计到上线，就像是一场接力赛一样，中途任一环节的失误都是可能会对结果造成不良影响的。在产品上线前，我一般会做以下几个事情（就像飞行员起飞前的检查一样，作为上线的checkList使用）：

1. 首先要保证测试环境全量回归流程测试没有发现新问题，具体回归包括但不限于核心GUI流程回归、全量API自动化回归及GUI自动化回归（如果有的话）。特别要注意的是，虽然测试负责人不可能事无巨细地验证每个测试用例，但核心的产品功能，测试负责人一定要去验收！测试环境回归未发现问题后，就先后更新服务端和客户端到预生产环境进行回归，同时产品同学也可以在预生产环境中配置业务数据、验收需求等。预生产环境回归测试没有发现新问题后，就开始准备更新到生产环境。

2. 但在更新生产前，一定要检查当次版本的服务端配置、业务数据配置。这是每次发版一定会做的事情，工作中也出现过几次因配置数据有问题，导致发布后线上出问题的情况。产品上线前，运维同学一定要仔细核对服务端配置、业务数据配置，防止遗漏、错误；上线后就算出问题，也不用着急，版本回退后排查原因，修复问题即可。

3. 就算检查过服务端配置、业务数据配置，我们还是无法彻底消除Bug。因此，为了尽可能地减小Bug的影响，我们会进行灰度发布，即更新部分服务端节点，将部分线上流量切到更新后的服务端上。这个时候，测试工程师在生产中回归核心流程，同时观察线上反馈，没有发现问题就代表更新没问题，可以将全部服务端更新到生产。

4. 服务端更新完毕后，客户端就可以更新了。客户端更新完毕后，测试工程师要在生产环境中，交叉回归测试当次迭代的新需求以及核心流程。需要注意的是，生产环境毕竟是给用户使用，因此我们不能干扰线上数据，就算不得已制造出了数据，也要立马删掉。也有的团队，会在预生产环境或生产环境中，使用专属的测试号做GUI自动化，这也不失为一种很好的回归测试方法（专属的测试号在数据库中带有特殊标识，产生的数据不会对用户有影响）。

5. 如果在生产中发现之前未测试出的问题，也不要着急，评估问题的严重程度，如果严重的话，在问题产生大的影响前修复掉（一般严重的问题不会在生产中出现，不然测试工程师也太不称职了）；如果是轻微的问题，可以放在下一版本中修复；当然，没问题是最好最棒的了。生产回归完毕，当次迭代就结束啦，可以进入下一迭代啦。