關於版本迭代的那些事

緣起：因爲以前公司資金的一些問題，沒法繼續經營下去，被迫離開了原來的公司，進入一個新的公司，發現周圍的新同事有事沒事就喜歡聊區塊鏈，人工智能之類的，我以爲相互學習研究技術沒毛病，但必定是在完成本職工做的前提，不管作哪一行工做都是同樣。。。很少說了，出於公司服務端版本的一些問題，進而整理一些，以備不時之需。

 

開發一個項目的時候版本迭代基本上是一個星期一次,爲了配合端進行了最簡單的 版本控制(分文件請求地址的控制)後來發現到後面一次性要維護,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.當下一版本需求定位有有必定改變或跨度時,應當使用區分版本升級

 

注：作版本控制以前，請務必根據業務請求結合實際作好分析。