1.开发规范-- 常用的版本控制

常用的版本控制

前言

这里版本控制是经过笔者在项目中实践总结得出的,有比较广的适用范围, 当然也要根据不同的业务有取舍应为笔者水平有限,其中有不足的地方也 往大家指出,多多交流

1.对于笔者采用的版本控制的介绍

对于版本控制 我这边是这样做的 两条路线,
1.大版本控制,也就是所谓的通过请求的url进行控制(当然也可以在参数进行大版本控制)
2.小版本控制,通过参数进行细小的版本控制

1.1 大版本控制

对于大版本控制就是所谓的在url里面进行控制,举个例子:

http://api.map.baidu.com/api?v=2.0&ak=您的密钥(百度地图API)
他这里使用的就是参数进行版本控制v=2.0,通过参数的路由指定到不同的项目
如果在请求地址里面进行版本控制就是这样
http://api.map.baidu.com/api/v2.0?ak=您的密钥

在这里比较推荐第二种因为参数控制可以留到更小的版本进行控制,如果是第一种需要在多传递一个版本参数会显得很累赘

一般大版本控制基本上是对第一位和第二位进行控制可以根据业务需求进行取舍

1.2 小版本控制

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

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

2.莫个接口增加或者是删除了几个返回值

3.莫个接口增加了一点点逻辑

例子如下:

http://api.map.baidu.com/api/v2.0?v=2.0.2
http://api.map.baidu.com/api/v2.0?v=2.0.3
比如2.0.2请求的时候需要返回4个参数
而2.0.3只需要返回2个参数
在迭代升级中不需要重新开启一个项目而进行小版本控制会来的更快更好管理

2. 为什么要区分大小版本

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

接着我们说能真真解决什么问题:

从上面的例子笔者相信大家可以看出,如果有一次升级迭代只拥有大版本控制的项目是不是需要在建立一套项目,当然是肯定的,到后 面的开发中进过的版本迭代越多,需要维护的版本就越来越对,如果有一天很早之前一个接口曝出了BUG那是不是这个版本之后的所有 只要是继承了这个方法的项目都要改,如果都已经上线了进行着一系列修改的风险比较大,应为动刀的项目比较多,能够缩小这一问题 的比较好的方法就是把能兼容的版本尽量的兼容,但是又要做到灵活,那么小版本控制是一个非常好的方法.

3. 在什么时候进行兼容,什么时候切分一个大版本呢?

其实在市面上流行的还有一种做法,一套项目兼容所有版本,大家也可以自己考虑一下这种方法的可行性,当然莫些业务需求会用到, 但在这里并不推荐使用,这样做的问题在于对于一个接口的逻辑在后期会相当复杂难以维护,笔者公司之前交给外包公司做的一个项目 就是采用这种方式,到后面实践下来暴露了很多很多的问题.

在这里笔者也进行了一些梳理,在什么时候进行兼容,在什么时候进行版本切分,可以提供给大家参考参考:

3.1. 对于web后端

对于web端实行同步更新,有且只有一个后端版本存在,与web同时上线迭代更新.

例子:

如现在线上有一套web和后端版本,新的开发任务完成后,线上的版本进行下线, 新的版本进行上线.

3.2. 关于APP后端

对于APP端要区别对待,分别为以下几大点:

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.当下一版本需求定位有有一定改变或跨度时,应当使用区分版本升级

4. 总结

在这里这篇简短的版本控制说明就到这里,希望大家能从中收获到一些灵感,但是请注意务必根据业务请求结合实际.