軟件程序的灰度發(fā)布控制方法和灰度發(fā)布控制裝置的制造方法
【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及軟件處理領(lǐng)域，具體涉及一種軟件程序的灰度發(fā)布控制方法和灰度發(fā) 布控制裝置，能夠通過對軟件的灰度發(fā)布與否進行判定，并利用用戶對灰度發(fā)布版本的反 饋結(jié)果對灰度發(fā)布過程進行控制，從而減少軟件發(fā)布的風(fēng)險。
【背景技術(shù)】
[0002] 當(dāng)前隨著移動互聯(lián)網(wǎng)的快速發(fā)展，各種SaaS(軟件即服務(wù)）軟件廠商為了搶占寶 貴的市場機會，都加快了SaaS系統(tǒng)軟件發(fā)布和更新的速度。有些大的軟件公司甚至開發(fā)了 可每日發(fā)布的軟件發(fā)布平臺。但是隨著軟件發(fā)布時間的縮短和發(fā)布頻率的增加，軟件發(fā)布 帶來的風(fēng)險也越來越明顯。如果新發(fā)布的軟件存在明顯的技術(shù)問題，對公司帶來的損失是 非常嚴重的。
[0003] 為了控制和減少軟件發(fā)布的風(fēng)險，一些互聯(lián)網(wǎng)公司開始采用新的軟件發(fā)布方式即 灰度發(fā)布。在灰度發(fā)布中，同時發(fā)布穩(wěn)定版本的軟件和試用版本的軟件，設(shè)定大部分的客戶 繼續(xù)之前的穩(wěn)定版本的軟件，而只設(shè)定小部分的用戶訪問試用版本，這樣即使試用版本的 軟件存在問題影響范圍只是有限的小部分用戶，從而有效減少了軟件發(fā)布的風(fēng)險。
[0004] 例如，中國專利申請No:201110333921. 6提供了一種灰度發(fā)布的處理方法及系 統(tǒng)，如圖1所示，它把穩(wěn)定版本的軟件和試用版本的軟件分別放在不同的服務(wù)器上，在運行 服務(wù)器前端添加了代理服務(wù)器，在代理服務(wù)器中安裝了試用IP列表和客戶訪問判斷模塊。 在用戶A請求服務(wù)時，先在代理服務(wù)器中判斷該A客戶是否在試用IP列表中。如果在就把 請求轉(zhuǎn)發(fā)到試用版本中，如果不在試用IP列表中就把請求轉(zhuǎn)發(fā)到穩(wěn)定版本中。
[0005] 但是這樣的灰度發(fā)布存在以下三個問題：
[0006] (1)由于灰度發(fā)布過程中需要同時維護多個版本的軟件，所以相比傳統(tǒng)發(fā)布方式， 灰度發(fā)布要花費軟件人員更多的時間和精力，因此需要有一種方法，能夠在軟件系統(tǒng)每次 更新之前判斷是否真的需要做灰度發(fā)布；
[0007] (2)在一般的灰度發(fā)布過程中，試用用戶占所有用戶的比例以及試用用戶列表都 是隨機選擇和生成的，沒有一個具體的數(shù)學(xué)模型去計算這樣的參數(shù)值；
[0008] (3)傳統(tǒng)的軟件發(fā)布過程僅僅考慮軟件廠商的自己的利益而沒有真正考慮終端客 戶的感受，比如SaaS系統(tǒng)更換了軟件的前端頁面設(shè)計，將會影響到終端客戶的使用方式和 使用感受。所以應(yīng)該考慮讓終端客戶也參與到SaaS系統(tǒng)的發(fā)布和更新過程中。

【發(fā)明內(nèi)容】

[0009] 為了解決現(xiàn)有技術(shù)的上述問題提出了本發(fā)明。因此，本發(fā)明的目的之一是提出一 種軟件程序的灰度發(fā)布控制方法和灰度發(fā)布控制裝置，能夠通過對軟件的灰度發(fā)布與否進 行判定，并利用用戶對灰度發(fā)布版本的反饋結(jié)果對灰度發(fā)布過程進行控制，從而減少軟件 發(fā)布的風(fēng)險。
[0010] 為了實現(xiàn)上述目的，根據(jù)本發(fā)明，提出了一種軟件程序的灰度發(fā)布控制方法，包 括：從軟件程序的功能函數(shù)中確定該軟件程序的核心函數(shù)；針對所確定的軟件程序的所有 核心函數(shù)，確定修改后的待發(fā)布的最新的軟件程序相對于當(dāng)前正在運行的軟件程序的整體 源碼變化率；以及在所述整體源碼變化率超過或等于預(yù)定的閾值的情況下，將所述最新的 軟件程序作為試用版本而將當(dāng)前正在運行的軟件程序作為穩(wěn)定版本進行灰度分布。
[0011] 優(yōu)選地，所述方法還包括：在對該軟件程序進行灰度分布時，對于該軟件程序中源 碼變化率較大的核心函數(shù)，根據(jù)運行日志信息確定其所對應(yīng)的通常訪問用戶和通常訪問時 間，從而確定針對所述灰度發(fā)布的試用用戶和試用時間。
[0012] 優(yōu)選地，所述核心函數(shù)是通過根據(jù)從軟件運行服務(wù)器中獲取的該軟件程序的運行 日志信息進行函數(shù)的調(diào)用頻率分析而確定的。
[0013] 優(yōu)選地，所述核心函數(shù)是通過由程序開發(fā)者指定來確定的。
[0014] 優(yōu)選地，所述方法還包括：在進行灰度發(fā)布時，根據(jù)實時從試用版本的運行服務(wù)器 中獲取的作為日志記錄的函數(shù)出錯率和客戶對新版本的使用反饋信息，判斷是停用該試用 版本還是將該試用版本采用為新的穩(wěn)定版本。
[0015] 優(yōu)選地，所述軟件程序包括軟件即服務(wù)程序，即，SaaS軟件程序。
[0016] 另外，根據(jù)本發(fā)明，還提出了一種軟件程序的灰度發(fā)布控制裝置，包括：從軟件程 序的功能函數(shù)中確定該軟件程序的核心函數(shù)的單元；針對所確定的軟件程序的所有核心函 數(shù)，確定修改后的待發(fā)布的最新的軟件程序相對于當(dāng)前正在運行的軟件程序的整體源碼變 化率的單元；以及在所述整體源碼變化率超過或等于預(yù)定的閾值的情況下，將所述最新的 軟件程序作為試用版本而將當(dāng)前正在運行的軟件程序作為穩(wěn)定版本進行灰度分布的單元。
[0017] 本發(fā)明能夠根據(jù)系統(tǒng)的檢測和用戶的反饋來減少軟件版本發(fā)布的風(fēng)險，同時提高 軟件由試用版轉(zhuǎn)化為穩(wěn)定版本的效率。通過該系統(tǒng)的應(yīng)用，軟件試用人員能夠通過簡單易 用的用戶圖形界面提供使用軟件系統(tǒng)的反饋信息，以助于系統(tǒng)的改進。同時，軟件開發(fā)人員 能夠及時得到系統(tǒng)和用戶對程序代碼功能、質(zhì)量等的反饋，及時提高軟件開發(fā)及修正的進 度。
【附圖說明】
[0018] 通過參考以下組合附圖對所采用的優(yōu)選實施方式的詳細描述，本發(fā)明的上述目 的、優(yōu)點和特征將變得更顯而易見，其中：
[0019] 圖1是示出了傳統(tǒng)發(fā)布和灰度發(fā)布的系統(tǒng)結(jié)構(gòu)差別的圖。
[0020] 圖2是示出了根據(jù)本發(fā)明的處于灰度發(fā)布系統(tǒng)中的灰度發(fā)布控制服務(wù)器的具體 結(jié)構(gòu)的框圖。
[0021] 圖3是示出了根據(jù)本發(fā)明的灰度發(fā)布系統(tǒng)架構(gòu)的一個示例的圖。
[0022] 圖4是示出了根據(jù)本發(fā)明的灰度發(fā)布方法的主要流程的圖。
[0023] 圖5是示出了根據(jù)本發(fā)明的灰度發(fā)布方法的過程001的具體處理的流程圖。
[0024] 圖6是示出了根據(jù)本發(fā)明的灰度發(fā)布方法的過程002的具體處理的流程圖。
[0025] 圖7是示出了灰度發(fā)布客戶反饋GUI(圖形用戶界面）的一個示例的示意圖。
[0026] 圖8是示出了根據(jù)本發(fā)明的灰度發(fā)布方法的過程003的具體處理的流程圖。
【具體實施方式】
[0027] 為使本發(fā)明的上述目的、特征和優(yōu)點更加明顯易懂，以下結(jié)合附圖和具體實施例 進一步詳細描述本發(fā)明。需要說明的是，附圖中的各結(jié)構(gòu)只是示意性的而不是限定性的，以 使本領(lǐng)域普通技術(shù)人員最佳地理解本發(fā)明的原理，其不一定按比例繪制。下面將結(jié)合附圖 對本發(fā)明的實施例進行詳細說明。
[0028] 本發(fā)明的特征是在原來開發(fā)服務(wù)器、運行服務(wù)器和代理服務(wù)器之外，添加了灰度 發(fā)布控制器。如圖2所示，該灰度發(fā)布控制服務(wù)器與開發(fā)服務(wù)器、運行服務(wù)器和代理服務(wù)器 相連接，從開發(fā)服務(wù)器、運行服務(wù)器獲取相關(guān)數(shù)據(jù)，并基于數(shù)據(jù)分析結(jié)果來設(shè)置代理服務(wù)器 從而實現(xiàn)灰度發(fā)布的控制。
[0029] 圖2示出了根據(jù)本發(fā)明的處于灰度發(fā)布系統(tǒng)中的灰度發(fā)布控制服務(wù)器的具體結(jié) 構(gòu)。該灰度發(fā)布控制服務(wù)器主要包括4個模塊 ：
[0030] 1.運行分析模塊
[0031] 該運行分析模塊與軟件運行服務(wù)器（圖2所示的運行服務(wù)器1和/或運行服務(wù)器 2)連接，并從軟件運行服務(wù)器中獲取運行日志信息。由于軟件的每一個功能和任務(wù)的都是 基于程序中一個或者多個的功能函數(shù)來實現(xiàn)，而這些函數(shù)被調(diào)用一次就在運行日志中增加 一條記錄，記錄包含了調(diào)用用戶信息、函數(shù)名字、被調(diào)用時間以及執(zhí)行結(jié)果等。
[0032] 通過分析這些日志信息，我們可以統(tǒng)計出功能函數(shù)被調(diào)用的順序和每個功能函數(shù) 被調(diào)用的次數(shù)等。作為示例，可以將調(diào)用函數(shù)頻率最高的前N個函數(shù)稱為核心函數(shù)，其中N 是用戶可以設(shè)定的值。當(dāng)然，選擇核心函數(shù)的方式并不局限于此。
[0033] 有些函數(shù)調(diào)用頻率不高但是非常重要，如果出錯的話軟件發(fā)布風(fēng)險非常高，對于 這種核心函數(shù)系統(tǒng)提供了一種交互界面，自動顯示出所有功能函數(shù)以及他們之間的調(diào)用關(guān) 系，由開發(fā)者手動指定哪些是核心函數(shù)。
[0034] 2.源碼變化分析模塊
[0035] 程序員在修改和測試完最新的軟件源碼后會提交到源碼管理服務(wù)器上，比如SVN 或者github上。源碼變化分析模塊會連接到源碼管理服務(wù)器上，自動分析核心功能函數(shù)所 對應(yīng)的源碼變化率。如下是一種計算源碼變化率的方法。
[0036] 由于在運行日志中已經(jīng)記錄了每個功能函數(shù)的源碼所在的文件比如java文件， 通過查找對應(yīng)的函數(shù)名可以找到功能函數(shù)的源碼在java文件中的具體中具體行數(shù)。通過 查找同一函數(shù)在不同版本代碼中的位置來比較函數(shù)中每一行代碼是否有改變，并計算改變 的代碼行數(shù)和原來總的行數(shù)比例得到每一個函數(shù)的變化比例Si。
[0037]Si=(函數(shù)添加、刪除、修改行數(shù)）/總代碼函數(shù)
[0038] 這里比如在版本VI中用戶登錄函數(shù)loginActionO在Login,java中的3~13 行，而在最新版本V2中用戶登錄函數(shù)loginActionO在Login,java中的3~15行，在比 較每一行后發(fā)現(xiàn)新添加了 2行代碼，則用戶登錄函數(shù)的變化是比例是20 %。
[0039] 該軟件程序的整體源碼的變化率S可以定義為所有核心函數(shù)的變化率Si均值：
[0040]S= (Sl*ffl+S2*W2+. .SN*ffN)/N
[0041]N是核心函數(shù)的數(shù)量，Wi是每個函數(shù)的加權(quán)值，這里
[0042]ffi=Ni/(N1+N2+-NN)
[0043]Ni日志中記錄的第i個核心函數(shù)訪問的次數(shù)。
[0044] 然后，可以對整體源碼變化率S和設(shè)定的變化率經(jīng)驗閾值（預(yù)定的閾值）。如果超 出或等于經(jīng)驗閾值，說明系統(tǒng)的發(fā)布的風(fēng)險比較高，則系統(tǒng)推薦使用灰度發(fā)布。如果變化率 小于經(jīng)驗閾值則不推薦灰度發(fā)布。
[0045] 如果計算結(jié)果是需要執(zhí)行灰度發(fā)布，系統(tǒng)會繼續(xù)統(tǒng)計日志信息來計算灰度發(fā)布所 需要的一些參數(shù)信息，比如試用用戶列表和試用時間。由于之前系統(tǒng)已經(jīng)計算出那些變化 率比較大的核心函數(shù)，所以只需要統(tǒng)計出那些源碼變化率大的核心函數(shù)所對應(yīng)的通常訪問 的用戶和通常訪問的時間，就可以計算出針對每次軟件更新的最有效的試用用戶和試用時 間。
[0046] 3.灰度發(fā)布控制模塊
[0047] 基于前兩步模塊的計算可以得出灰度發(fā)布的一些重要參數(shù)值，比如是否需要灰度 發(fā)布、灰度發(fā)布的用戶列表和灰度發(fā)布的時間?；叶劝l(fā)布控制模塊主要控制發(fā)布的過程，以 及在代理服務(wù)器中設(shè)定灰度發(fā)布的用