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. 總結##

在這裏這篇簡短的版本控制說明就到這裏,但願你們能從中收穫到一些靈感,可是請注意務必根據業務請求結合實際.