关于版本迭代的那些事

缘起：由于之前公司资金的一些问题，无法继续经营下去，被迫离开了原来的公司，进入一个新的公司，发现周围的新同事有事没事就喜欢聊区块链，人工智能之类的，我觉得相互学习研究技术没毛病，但一定是在完成本职工作的前提，无论做哪一行工作都是一样。。。不多说了，出于公司服务端版本的一些问题，进而整理一些，以备不时之需。

 

开发一个项目的时候版本迭代基本上是一个星期一次,为了配合端进行了最简单的 版本控制(分文件请求地址的控制)后来发现到后面一次性要维护,3到5个版本而且真正上的逻辑差别都不大,只是为了做到配合端做好 版本控制,后来意识到这种方式在这种快速开发中是不可取得,在后面的了解和探索中发现了大小版本控制比较适合。

一.对于web服务端和App服务端要区别对待

对于web端实行同步更新,有且只有一个后端版本存在,与web同时上线迭代更新.例如：现在线上有一套web和后端版本,新的开发任务完成后,线上的版本进行下线, 新的版本进行上线。只需保证好代码备份回滚就好～

对于，App服务端来讲，版本控制要严格把控一下了，以下主要是对App服务端来讲。

二.小版本控制

对于小版本控制存在的意义在于在一次迭代中接口改动很小但是有个别接口有轻微的逻辑变化,比如:

(1)在下一个版本中有一个接口取消了不允许被访问了 

(2)某个接口增加或者是删除了几个返回值 

(3)某个接口增加了一点点逻辑

例:
http://127.0.0.1/api/v2.0?v=2.0.2
http://127.0.0.1/api/v2.0?v=2.0.3

比如2.0.2请求的时候需要返回4个参数 
而2.0.3只需要返回2个参数 
在迭代升级中不需要重新开启一个项目而进行小版本控制会来的更快更好管理

 

三.切分一个大版本

(1)App端访问地址形式通常是http://xxxx/项目名称/版本号(两位如:1.0;1.1;)/参数 

(2)每个接口访问必须带有参数version作为一个版本号传递参数(三位如:1.0.1;1.0.3) 

(3)无论版本迭代多少次之前版本无特殊情况不允许做任何删除操作 

(4)在开发中数据库结构,以及代码层面必须对之前版本兼容,不能对历史版本有影响对于不同的迭代版本采用以下规则进行(兼容)或(区分项目)操作:

以下情况进行兼容操作:(所谓兼容就是多个版本请求同一个地址传递的version不同,代码层面的区分业务逻辑)
1.当下一版本业务逻辑变化不大,单接口无较大修改(所谓较大修改规定为单接口原有工作量的30%)优先选择兼容迭代 
2.当下一版本上线周期小于3周或开发周期小于2周时,优先选择兼容迭代 
3.当下一版本有新增接口时,优先选择兼容迭代 
4.当前一版本未上线,优先选择兼容迭代 
5.当兼容版本小于3个,上线版本小于2个,优先选择兼容迭代 
6.当满足区分版本中的任意一个条件,必须选择区分版本迭代
 
以下情况进行区分版本:(所谓区分版本就是调用的链接本质上的不同指向的项目区别对待,项目层面区分业务逻辑)
1.当兼容迭代版本超过3个或线上版本兼容2个,必须是用区分版本升级 
2.当下一版本周期大于3周或开发周期大于2周,必须选择区分版本升级 
3.当下一版本需求定位有有一定改变或跨度时,应当使用区分版本升级

 

注：做版本控制之前，请务必根据业务请求结合实际做好分析。