关于互联网产品发版管理的思考

         互联网的内卷化、竞争的特点要求互联网产品的发版必须要快，越快越好，相比传统项目按月、年计的发版节奏，互联网是按天、周的。除了快的特点外，版本多也是其重要特点，针对不同用户、不同渠道往往投放不同的个性化定制版本，如何管理这些版本，如何保证版本质量值得深思。

     结合目前整个发版的生命周期，看看该如何优化，发版的流程如下：开发—测试—发版—用户体验，整个是串行的工作方式，须逐项优化

1、开发：隔离和浅修改

    要做到发版快，只有并行的方式，多个需求多人并行开发-测试-验收，然后合并到发布分支发版，目前开发测试产品团队基本都是采用此模式，一个开发、一个产品、一个测试组成一个需求从提出到落地的三人小组，需要着重注意的是多人并行开发的模式需要从代码架构方面予以保证，不然多人并行开发带来的是更多的混乱。如何控制多人并行开发而互相影响最小呢？其实就是隔离，只有冲突才会带来混乱。站在代码工程的角度，可将代码分为从上至下的结构：

底层偏基础（网络请求、数据存储、开源第三方框架）基本不涉及业务，抽象程度最高；

中层偏业务，类似于领域业务模型，不涉及ui、供多个ui界面共用的业务数据处理，抽象程度居中；

上层偏ui界面，紧贴产品ui交互，基本无抽象。

     各业务开发者大部分操作都局限在上层，操作效果也明显，也容易发现问题；偶尔涉及中层的数据处理修改。从修改代码的角度，修改靠底层的影响越大；修改靠上层的影响越小。这样的话，各开发者的修改相对隔离，而且修改范围层次较浅，影响较小。

关于问题修复一般分两种情况：

1、短时间可修复的bug，修复后更新版本

2、短时间无法修复的，回退

2、发版：区分toB和toC

      根据版本交付的直接对象不同，可将发版分为toB和toC两种情况：toC就是面向普通市场用户，是产品的直接使用者；toB就是面向合作伙伴，比如定制化交付的对象，先给到toB，然后再给到toC，最终也是面向市场普通用户的，只不过通过toB中转了一道。

     toC的发版就像赶火车，需求验收通过赶得上火车的，就跟着发版走；赶不上的，就下趟。赶上了，火车刚运行发现问题的，抓紧修复，短时间无法修复的，进行回退。发版质量不好是会影响c端用户的体验。但若是toB的发版，比如定制化、个性化的输出到B端，B端再通过渠道投放给C端，由于中间多了一道toB的关卡，倘若发版不好，则会多了一层B端的影响，会影响客户关系，不利于后续合作开展，因此，B端的发版，必须基于经过C端验证的稳定的市场版本，B端的发版节奏必须要落后于C端的发版。

3、用户侧：范围逐步扩大

      版本的质量离不开测试，测试分为内部测试和外部测试，发版范围先由内部测试团队进行专项测试，发现问题，修复版本；内部测试无问题后，再投放到外部，外部范围可以由小及大，先选中特定用户进行升级更新，后台监控问题反馈，如有问题，修复版本，继续观察，直到上线结束