緣起：由於之前公司資金的一些問題，無法繼續經營下去，被迫離開了原來的公司，進入一個新的公司，發現周圍的新同事有事沒事就喜歡聊區塊鏈，人工智能之類的，我覺得相互學習研究技術沒毛病，但一定是在完成本職工作的前提，無論做哪一行工作都是一樣。。。不多說了，出於公司服務端版本的一些問題，進而整理一些，以備不時之需。
開發一個項目的時候版本迭代基本上是一個星期一次,為了配合端進行了最簡單的 版本控制(分文件請求地址的控制)后來發現到后面一次性要維護,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.當下一版本需求定位有有一定改變或跨度時,應當使用區分版本升級
注：做版本控制之前，請務必根據業務請求結合實際做好分析。