#常用的版本控制# ##前言## 這裡版本控制是經過筆者在專案中實踐總結得出的,有比較廣的適用範圍, 當然也要根據不同的業務有取捨應為筆者水平有限,其中有不足的地方也 往大家指出,多多交流

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

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