戶列表。
[0048] 在灰度發(fā)布過程中也可以讓終端用戶參與進來，比如對新版本的界面的使用體驗 進行評分和添加意見。
[0049] 在手動或用自動化工具部署完試用版本服務(wù)器之后就可以開啟灰度發(fā)布，讓客戶 同時訪問穩(wěn)定版本和試用版本。在灰度過程中自動開啟反饋分析模塊，實時從試用服務(wù)器 中獲取日志記錄函數(shù)出錯率和客戶反饋。如果超出設(shè)定的閾值就自動關(guān)閉灰度發(fā)布，或把 試用的用戶比例調(diào)整為零。
[0050] 如果沒有自動關(guān)閉灰度發(fā)布，則在規(guī)定的時間點到達后停止灰度發(fā)布。
[0051] 4.反饋分析模塊
[0052] 在灰度發(fā)布執(zhí)行過程中或停止后，反饋分析模塊主要對灰度發(fā)布中運行數(shù)據(jù)進行 記錄和統(tǒng)計分析。這里的運行數(shù)據(jù)主要包括2方面的數(shù)據(jù)：（1)運行日志中每個函數(shù)的運 行結(jié)果；(2)用戶的評價信息，用于分析用戶是否對新版本的使用體驗比較滿意。
[0053] 系統(tǒng)管理員基于分析結(jié)果判斷是否采用試用版本，如果新的試用版本效果很好， 管理員可以調(diào)整試用用戶的比例為100 %，重啟灰度發(fā)布，這樣試用版本將變成最新的穩(wěn)定 版本；如果新的試用版本效果較差，比如函數(shù)錯誤率超過50%，系統(tǒng)管理員需要通知開發(fā) 工程師繼續(xù)優(yōu)化和改進源碼，準備下一次灰度發(fā)布。
[0054]本發(fā)明的一個實施例如圖3所示。圖3是一個灰度發(fā)布控制器的架構(gòu)圖的示例， 該灰度發(fā)布控制器包括：后端處理系統(tǒng)以及前端交互界面。后端處理系統(tǒng)與開發(fā)服務(wù)器或 源碼管理服務(wù)器、運行服務(wù)器之間有數(shù)據(jù)接口，與代理服務(wù)器之間存在命令接口。后端服務(wù) 器內(nèi)部包含四個程序模塊：程序運行分析模塊、代碼變化分析模塊、灰度發(fā)布管理模塊、試 用反饋分析模塊。后端服務(wù)器內(nèi)部包含一個數(shù)據(jù)庫，用于保存數(shù)據(jù)分析結(jié)果、前端數(shù)據(jù)的展 示以及保存用戶交互的數(shù)據(jù)。
[0055] 圖4示出了根據(jù)本發(fā)明的灰度發(fā)布方法的主要流程
[0056] 該流程包含四個：運行分析、源代碼變化分析、灰度發(fā)布控制及反饋分析。
[0057] 運行分析的作用是分析用戶使用軟件的日志、對不同方法的調(diào)用進行分析和排 序，得出使用頻率高的核心方法列表。同時，管理員也能通過GUI，方便手動設(shè)置雖然訪問量 低，但是代表了核心業(yè)務(wù)的核心函數(shù)。這些函數(shù)名稱及用戶請求ID都會被記錄在運行日志 數(shù)據(jù)結(jié)構(gòu)中。
[0058] 源碼變化分析的作用是比較分析由開發(fā)者上傳到代碼托管服務(wù)器（SVN或Git)的 代碼與原始代碼的差別，通過一系列的數(shù)學(xué)方法得出每個核心方法的源碼改變率數(shù)值。然 后通過和設(shè)置的閾值進行比較，系統(tǒng)能夠自動推斷當前最新版本的程序是否需要進行灰度 發(fā)布。然后，會生成每個核心模塊的用戶列表和執(zhí)行時間。
[0059] 灰度發(fā)布控制的作用是配置灰度發(fā)布參數(shù)并管理整個灰度發(fā)布的循環(huán)流程。如果 系統(tǒng)判斷軟件需要使用灰度發(fā)布，接下來，灰度發(fā)布控制模塊將根據(jù)核心函數(shù)的使用率和 改變率，設(shè)置相應(yīng)的灰度發(fā)布參數(shù)值來管理整個灰度發(fā)布的循環(huán)流程。
[0060] 反饋分析的作用是收集用戶的軟件版本使用反饋，分析用戶對灰色發(fā)布版本的反 饋并且判斷試用版本是否運行順利，用戶是否對灰度發(fā)布滿意。
[0061] 如上所述，本發(fā)明提供了一種方法，能基于軟件的開發(fā)數(shù)據(jù)和運行數(shù)據(jù)自動判斷 每次更新之后的軟件是否需要執(zhí)行灰度發(fā)布，并管理和執(zhí)行灰度發(fā)布的過程，同時讓終端 用戶也能參與到軟件發(fā)布過程中，最后自動分析灰度發(fā)布的結(jié)果。
[0062]如下所示的表1展示了運行日志結(jié)構(gòu)，其中包括：用戶使用的應(yīng)用程序名稱、用戶 信息、用戶的請求ID、調(diào)用的函數(shù)名及此函數(shù)涉及的代碼行范圍、調(diào)用代碼所屬的類名和文 件名、代碼調(diào)用時間、方法調(diào)用結(jié)果（成功/失?。Ｔ撊罩居脕碛嬎愫捅容^不同調(diào)用之間 的S值，也即源碼改變率數(shù)值。
[0063]表1
[0064]
[0065]圖5示出了根據(jù)本發(fā)明的灰度發(fā)布方法的過程001的具體處理。該過程由運行分 析子過程和源代碼變化分析子過程組成。每個軟件系統(tǒng)由不同的函數(shù)組成。不同的函數(shù)組 合順序表明了不同的業(yè)務(wù)需求。通過這兩個模塊在步驟101分析系統(tǒng)的運行狀態(tài)，得到函 數(shù)的調(diào)用順序，并在步驟102分析函數(shù)調(diào)用頻率，得到核心函數(shù)列表，其中大于N次的方法 被定義為核心函數(shù)。這些定義能夠以圖形化的方法展示在管理員⑶I界面，因此管理員能 夠看到自動更新的記錄，同時也能夠手動標記他們認為的核心函數(shù)。
[0066] 當開發(fā)人員更新程序源代碼的時候，我們需要知道這些改變是怎樣影響程序的運 行環(huán)境和業(yè)務(wù)邏輯。因此當程序員把代碼上傳到代碼倉庫的時候，運行分析模塊和源代碼 變化分析模塊在步驟103中，能夠自動比較新舊代碼并判斷核心方法是否被修改，并同時 計算核心方法和修改頻率平均值S。這里，S= (S1*W1+S2*W2+. ·WN*SN)/N，Si=(函數(shù)添 加、刪除、修改行數(shù)）/總代碼函數(shù)。N是核心函數(shù)的數(shù)量，Wi是每個函數(shù)的加權(quán)值，這里Wi =NV(N1+N2+…NN)，Ni是日志中記錄的第i個核心函數(shù)訪問的次數(shù)。通過比較運行日志 結(jié)構(gòu)中的類名，文件名及代碼起始位置，就能夠得出Si的值。
[0067]在步驟104中，如果上述的這些代碼改變涉及到核心函數(shù)并且整體源碼改變率高 于事先設(shè)置的閾值，那么系統(tǒng)將會給管理員推薦使用灰度發(fā)布方法。否則，不使用灰度發(fā) 布。
[0068]在步驟105中，根據(jù)運行日志結(jié)構(gòu)中的用戶信息及代碼調(diào)用時間，系統(tǒng)能夠計算 出針對核心函數(shù)的記錄，并形成測試用戶列表。
[0069] 圖6示出了根據(jù)本發(fā)明的灰度發(fā)布方法的過程002的具體處理（灰度發(fā)布控制）。 過程002通過設(shè)置灰度發(fā)布的各種參數(shù)來管理程序發(fā)布的流程。在步驟201中，主要的參 數(shù)，比如"是否使用灰度發(fā)布""試用時間""試用用戶清單"能夠從過程001中計算出來。 其它參數(shù)，比如"試用用戶使用率"、"是否使用反饋信息"等，是管理員根據(jù)軟件升級類型來 定義的。在步驟202,將試用版本的軟件發(fā)布到運行服務(wù)器，并在步驟203中允許步驟201 中的試用用戶進行使用。步驟204中，如果"是否使用反饋信息"參數(shù)設(shè)置為真，用戶就可 以在試用的時候加入自己的反饋意見（步驟205)。
[0070] 在步驟206的運行過程中，該模塊會實時分析運行日志和用戶反饋。步驟207如 果分析結(jié)果比較好，則"試用用戶使用率"參數(shù)就增加。但是如果70%的試用失敗或者得到 10個錯誤，則試用版本將自動停止運行（步驟208)。這些閾值可以在GUI中手動設(shè)置。
[0071] 圖7示出了灰度發(fā)布客戶反饋GUI的一個示例，在圖例中，可以清楚地看到，用戶 在試用的過程中，對每個函數(shù)可以加入自己的反饋信息，勾選從"完美"到"非常壞"選擇， 也可以手動輸入別的信息。但是，需要指出的是，本發(fā)明并不局限于此。
[0072] 圖8示出了根據(jù)本發(fā)明的灰度發(fā)布方法的過程003的具體處理（灰度發(fā)布反饋分 析）。過程003運行于試用反饋分析模塊。試用結(jié)束后，步驟301從運行日志結(jié)構(gòu)中計算出 每個核心函數(shù)的運行結(jié)果。根據(jù)這些結(jié)果，管理員能夠基于如下兩種標準在步驟302中判 斷試用結(jié)果：
[0073]a.每個核心函數(shù)是否運行順利
[0074]b.是否大多數(shù)的用戶在評論中表示對系統(tǒng)滿意
[0075] 如果判斷結(jié)果是好的。則系統(tǒng)管理員在步驟303中將擴展用戶試用列表并且最終 把"試用用戶使用率"更改為1〇〇 %，也就意味著在步驟303中，試用版本變成了穩(wěn)定版本。 如果判斷結(jié)果是壞的，在步驟304中，開發(fā)人員就需要為了下一次灰度發(fā)布繼續(xù)改進代碼。
[0076] 以上列舉了若干具體實施例來詳細闡明本發(fā)明，這些個例僅說明本發(fā)明的原理及 其實施方法之用，而非對本發(fā)明的限制，在不脫離本發(fā)明的精神和范圍的情況下，本領(lǐng)域的 技術(shù)人員還可以做出各種變形和改進。因此，本發(fā)明不應(yīng)由上述實施例來限定，而應(yīng)由所附 權(quán)利要求及其等價物來限定。
【主權(quán)項】
1. 一種軟件程序的灰度發(fā)布控制方法，包括： 從軟件程序的功能函數(shù)中確定該軟件程序的核心函數(shù)； 針對所確定的軟件程序的所有核心函數(shù)，確定修改后的待發(fā)布的最新的軟件程序相對 于當前正在運行的軟件程序的整體源碼變化率；以及 在所述整體源碼變化率超過或等于預(yù)定的閾值的情況下，將所述最新的軟件程序作為 試用版本而將當前正在運行的軟件程序作為穩(wěn)定版本進行灰度分布。2. 根據(jù)權(quán)利要求1所述的方法，還包括： 在對該軟件程序進行灰度分布時，對于該軟件程序中源碼變化率較大的核心函數(shù)，根 據(jù)運行日志信息確定其所對應(yīng)的通常訪問用戶和通常訪問時間，從而確定針對所述灰度發(fā) 布的試用用戶和試用時間。3. 根據(jù)權(quán)利要求1所述的方法，其中， 所述核心函數(shù)是通過根據(jù)從軟件運行服務(wù)器中獲取的該軟件程序的運行日志信息進 行函數(shù)的調(diào)用頻率分析而確定的。4. 根據(jù)權(quán)利要求3所述的方法，其中， 所述核心函數(shù)是通過由程序開發(fā)者指定來確定的。5. 根據(jù)權(quán)利要求1所述的方法，還包括： 在進行灰度發(fā)布時，根據(jù)實時從試用版本的運行服務(wù)器中獲取的作為日志記錄的函數(shù) 出錯率和客戶對新版本的使用反饋信息，判斷是停用該試用版本還是將該試用版本采用為 新的穩(wěn)定版本。6. 根據(jù)權(quán)利要求1所述的方法，其中， 所述軟件程序包括軟件即服務(wù)程序，即，SaaS軟件程序。7. -種軟件程序的灰度發(fā)布控制裝置，包括： 從軟件程序的功能函數(shù)中確定該軟件程序的核心函數(shù)的單元； 針對所確定的軟件程序的所有核心函數(shù)，確定修改后的待發(fā)布的最新的軟件程序相對 于當前正在運行的軟件程序的整體源碼變化率的單元；以及 在所述整體源碼變化率超過或等于預(yù)定的閾值的情況下，將所述最新的軟件程序作為 試用版本而將當前正在運行的軟件程序作為穩(wěn)定版本進行灰度分布的單元。
【專利摘要】根據(jù)本發(fā)明，提出了一種軟件程序的灰度發(fā)布控制方法，包括：從軟件程序的功能函數(shù)中確定該軟件程序的核心函數(shù)；針對所確定的軟件程序的所有核心函數(shù)，確定修改后的待發(fā)布的最新的軟件程序相對于當前正在運行的軟件程序的整體源碼變化率；以及在所述整體源碼變化率超過或等于預(yù)定的閾值的情況下，將所述最新的軟件程序作為試用版本而將當前正在運行的軟件程序作為穩(wěn)定版本進行灰度分布。
【IPC分類】G06F9/45
【公開號】CN105335204
【申請?zhí)枴緾N201410367493
【發(fā)明人】魯時雨, 李軍
【申請人】株式會社日立制作所
【公開日】2016年2月17日
【申請日】2014年7月29日