这几年工作的一大体会就是，发布日益变成研发流程中重要的一环，甚至很多时候发布比研发本身还要关键。（代码没改几行，但是发布出错，那就是一个严重的事故）。移动互联网产品的Release本身也分为多个类型：1. 版本发布（AppStore, 各大应用市场更新），2. 服务发布（也叫周长发布，后台服务做了升级，或者代码做了重构等等），3. 紧急发布（Bug Fix, 线上出了紧急的故障，需要发版本升级）本文想讨论的，主要为1这种类型，接下来的内容也基于过去3年，我的团队的一些经验教训总结而成。

什么时候做Release Plan?

发布计划什么时候做，一般是上线前1到2天做。太早和太晚都不合适，主要原因是，提前太久做，项目还在执行中，很多细节根本定不下来，那时候做出来的计划基本上是不靠谱的。第二，那时候攻城狮们都在忙着干活呢，没有心思讨论具体的细节。发布当天做，更不行，发布当天，一堆事情需要梳理，那时候再来动笔，如果中途出现任何幺蛾子，效果可想而知。

Release Plan 包含哪一些内容？

一份发布计划，可以根据每次发布的内容来做适当的调整，所以不可能有万能的模板适合各种发布，但是以下几点，是建议要包括的：

1. 本次发布的参与人
2. 发布的范围
3. 是否有相关依赖（数据库schema更改，index update, 某些服务需要reloading, blabla..）
4. 发布的时间和顺序
5. 发布后的验证方案
6. 如果有不能解决的异常，回滚方案

对于以上几点，再做一下简单的说明, 第一点，其实是最重要的，每次发布，参与的人必须要明确，特别是发布前的准备会，所有相关同学必须要在场，大家要对整个流程达到高度的认知一致。另外，请注意，这里说的并不只是开发，测试，运维和产品这些常规角色，运营，法务，市场等角色也不能遗漏，上线后的验收是需要业务部门参与的。

第二点，不用多说，发布的范围必须要明确，本次发布，哪一些模块/功能需要上线。

第三点，现在的系统架构，包含了大量的中间件，一个功能的改动，很多时候不只是提现在代码的改动上，数据库，配置文件，缓存更新等等，对新功能都会有影响。如果代码更新上去了，发现表结构还是上一个版本，那就等P1事故吧。

第四点，发布日什么时候开始启动发布流程？上班后9点开始？下班后7点开始，还是凌点？各个模块的发布顺序一定要明确，毕竟很多时候，都是非停机发布。

第五点，新版本发布后那一刻，必须要有明确的验证方案，包含验证人，TestCase等，如果不能直接验证，那么更要提前造好对应的context以备做到第一时间进行确认。

第六点，我们任何时刻，都要做好最坏的打算，那就是发布失败，保持现有版本。

如何开好Release Plan的会议

发布计划的执行前，建议开一个发布会议，用来全员同步和确认发布计划。发布计划会议的主持人是本次项目的负责人或者项目经理。会议过程中，逐条过每一个要点，每一个要点过完后，明确责任人或者接口人。会议结束后，将发布计划达成的结果发给所有与会人。

Release Plan执行过程中的要点

1. 时刻做好Tracking和Monitor, 每做好一个点，打一个勾；如果出现异常情况，立刻Raise一个Yellow Flag乃至Red Flag.

2. 做好异常情况的应对，比方说，IDC机房或者第三方云主机出现故障，需要提前打好招呼，找到对应的接口人，而不是出事了，再来找人。

3. 发布前，要提前和业务方打好招呼，告知对应的发布计划，保证不会业务发布不会相互影响。

扫描二维码或手动搜索微信公众号： ForestNotes

欢迎转载，带上以下二维码即可