一種基于版本演進模型和迭代設計模式的軟件版本迭代方法

汪驥宇 陳武 張千秋 胡芳

摘要：在采用微服務架構設計軟件時，隨著軟件規模的增大，需要管理的微服務越來越多，微服務版本迭代也越來越多，對微服務的版本設計與管理越來越困難。為解決該問題，文章提出了基于版本演進模型和迭代設計模式的版本迭代方法，方法包括一個版本演進模型和一種迭代設計模式。版本演進模型是一個管理模型，包括軟件版本計劃管理、主倉庫、預發倉庫、開發倉庫、開發人員倉庫、緊急修復倉庫管理內容，實現軟件服務全生命管理。迭代設計模式中介紹微服務版本迭代的設計模式，指導設計人員進行軟件服務的版本設計。

關鍵詞：微服務;版本演進模型;迭代設計模式

中圖分類號：TP311? ? ? ? 文獻標識碼：A

文章編號：1009-3044（2022）14-0051-03

1 引言

微服務架構[1]從2014年被提出以來，成為軟件應用領域的熱門概念，是一種新的架構風格。其具有易開發、維護，獨立、易擴展、獨立部署等優勢[2]。近年來，隨著云計算技術的進步與服務量的不斷增長、DevOps的興起[3]，微服務架構正在成為軟件應用開發特別是復雜大型應用首選架構[4]。

軟件的快速迭代發布能夠給軟件服務的投資者帶來信心，也能夠在過程中發現問題以及外部環境變化，及時調整軟件的開發路線。隨著微服務項目的不斷增加，軟件服務規模擴大，如何有效進行軟件版本管理[5]、軟件迭代設計成為一個巨大的挑戰[6-7]。產品經理、架構師們不斷思考軟件服務的未來功能、版本規劃[8]，在進行軟件版本迭代設計時會遇到對于未來版本功能如何設計規劃的問題。

本文提出了一種基于版本演進模型和軟件迭代設計模式的版本迭代方法，提供了一種可行的版本演進模型以及基于該模型的設計模式。產品經理和架構師可以很好地進行基于微服務的軟件服務設計研發。

2 版本演進模型

本文設計的軟件服務版本演進模型包括5種類型倉庫和一個版本計劃：

1）主倉庫，為發布倉庫，也是生產倉庫。各個主版本編號在該倉庫中標識，1.0、2.0……標識大版本，1.1、1.2……標識由緊急修復發版產生的小版本。

2）緊急修復倉庫，這是管理緊急修復代碼系列分支的倉庫。當生產上出現需要緊急bug的時候，就可以從主倉庫中拉出代碼到緊急修復倉庫，建立E1分支進行修復，修復完成后，并入主倉庫形成小版本，修改的內容并入開發倉庫，E1e表示E1分支結束，E1、E2……標識緊急修復分支。

3）預發倉庫，這是管理預發分支的倉庫，管理預發分支用于用戶測試、上線測試的一個分支系列。當完成開發測試后，測試人員提交發布測試預發申請，由配置人員創建的預發倉庫分支。該分支發現的bug，依據從開發人員倉庫修復à開發倉庫版本分支à開發分支à預發倉庫分支路徑，依次推到該倉庫。該倉庫測試完成后，將推到主倉庫進行發布。用Pr1、Pr2……標識預發分支，Pr1e、Pr2e……表示對應預發分支結束。

4）開發倉庫，該倉庫指軟件開發過程的主要倉庫，管理主開發代碼分支和版本分支。在做新的功能、做bug修復時，是從這個倉庫分出來做。在這個倉庫下主開發代碼分支主要負責記錄開發狀態下相對穩定的版本，即完成了某個版本或者修復了某個bug后的開發穩定版本。版本分支是由許多分別負責不同版本開發分支組成的一個分支系列。開發測試主要基于版本分支進行，也可以從主開發分支進行，當版本功能點開發測試完畢之后，就會合并到主分支，對應版本分支結束。開發分支是一個連續的分支，用D0.0、D1.0、D1.1、D2.0……標識，與主分支版本對應。版本分支用F1、F2……標識，與大版本對應，F1e、F2e……表示對應開發版本分支結束。

5）開發人員倉庫，指開發人員的倉庫群，每個開發人員對應自己的倉庫，倉庫管理個人開發使用的分支，主要包括各個開發分支，分為版本開發分支和緊急修復分支兩大類分支。P1、P2……標識個人開發分支，與開發版本分支對應，P1e、P2e…表示對應個人分支結束。PE1、PE2……標識個人緊急修復分支，與緊急修復分支相對應，PE1、PE2……表示對應個人緊急修復分支結束。

6）版本計劃，每一個軟件服務的倉庫都需要有版本計劃，包括正常開發版本計劃和緊急修復版本計劃。任何開發開始前需要制訂版本計劃，配置人員根據計劃構建主倉庫、緊急修復倉庫、預發倉庫、開發倉庫以及在倉庫中建立代碼合適分支。

版本演進模型說明[9-13]：

1）在模塊開始開發前，由配置人員創建主倉庫、預發倉庫、開發倉庫、開發人員倉庫，給相關開發人員、測試人員建立賬號和完成倉庫授權。

2）各個模塊的敏捷專家制訂該模塊的版本計劃，開發負責人根據該計劃配置相關的開發倉庫。

3）開發人員在個人倉庫中建立版本分支，從開發倉庫版本分支中拉起代碼到個人版本分支，完成個人版本開發后提交合并到開發倉庫對應的版本分支。測試人員進行測試，測試的問題由開發人員在個人版本分支中修復，再推到開發倉庫版本分支。測試完成后，開發負責人將開發版本分支合并到開發倉庫，這里會存在多人協同開發以及bug修復多次提交。

4）版本分支開發完成后，開發負責人提出合并預發倉庫分支申請，由配置人員合并到預發倉庫分支，用戶進行功能確認測試。測試發現bug，由開發人員在個人開發分支中完成修復，之后參照上一步驟完成測試推送到預發分支，進行回歸測試。

5）完成預發測試后，開發負責人標識開發版本分支，提出預發倉庫合并到主倉庫申請，配置人員完成合并。合并完成后，開發負責人將開發主分支修改推送到正在進行的版本分支。開發人員需要從版本分支中更新修改到后續開發的個人分支中。

6）當生產環境發生緊急bug需要修復時，敏捷專家制訂緊急倉庫計劃，配置人員在緊急修復倉庫創建緊急修復分支，拉取主分支代碼。開發人員在個人倉庫中建立緊急修復分支，從該分支拉取代碼。bug修復后，提交到緊急倉庫，測試人員對緊急倉庫進行測試。測試完成后，開發負責人合并修復代碼到開發倉庫，同時提出緊急倉庫合并到主倉庫申請，配置人員完成合并。開發負責人先將緊急修復分支修改的內容同步到開發主分支，然后將開發主分支修改推送到正在進行的版本分支。開發人員需要從版本分支中更新修改到在后續開發的個人分支中。

3 迭代設計模式

軟件服務總體設計模式中，軟件高版本為低版本的升級替換，軟件服務迭代設計的設計模式總體架構如圖 1所示。本文中以高版本V2版、低版本V1版為例，V2版為V1版的升級版本。

在該模式總體架構中：

1）軟件服務的版本從低版本升級到高版本。

2）在該圖中功能和服務成對出現，相同編號表示為同一個模式相關組件。

3）軟件內部黑色箭頭表示組件內部功能的調用。

4）兩個版本間的箭頭表示軟件版本的變遷。

5）模式總體架構中包括6種模式：新增功能模式、功能等效模式、前端升版模式、前后端升版模式、新前端模式、前端升版+新后端模式。

6）在進行新版本功能設計時需要靈活應用這6種模式。

在軟件服務升版設計時，往往一個軟件功能需求可以采用多種設計模式來實現，在設計過程需要綜合考慮多種因素，包括團隊成員情況、進度、成本等因素。

團隊成員情況是最重要的一個因素，對于前一個版本已經對外提供服務，或者用于生產的情況下，如果團隊成員穩定、技術能力強，那么可以盡量采用服務升版的模式，這樣可以增加代碼的內聚性，后期維護工作量最小化;如果團隊成員變化較大、成員技術能力比較差，那么盡量采用新功能的模式，減少對原有服務代碼的修改，這樣能夠保障已發布功能的穩定性，但是會增加后期維護工作量。

進度、成本也是很重要的因素，如果研發時間、成本足夠，可以盡量采用服務升版的模式，盡可能地進行抽象、內聚的設計，優化相關代碼，減少維護成本。如果研發時間、成本壓力大，同時還涉及運維，那么對新功能往往會采用新功能的方式，復制一套代碼進行修改，這樣能夠短期完成新功能，同時又不影響已有功能，但這會大大增加后期的維護以及軟件的升級。

3.1 新增功能模式

1）模式概述

該模式是通過設計新的前端功能及服務來實現相關需求。

2）適用場景

該模式適用于以下幾種情況：

在應用低版本中沒有，需要設計新的功能。

高版本與低版本需求存在很大差異。

直接修改應用V1版功能滿足高版本需求但沒有效益，即在進度、成本、質量等方面無明顯收益。

3）設計說明

前端增加新的功能，這里V1/Req表示新的前端功能設計。

后端增加新的服務，這里V1/service1表示新的后端服務設計。

3.2 功能等效模式

1）模式概述

該模式指對模塊V1版相關功能實現不需要修改，模塊V2版中與V1版中沒有差異。

2）適用場景

該模式適用于以下幾種情況：

低版本和高版本的功能一致。

低版本已經考慮了高版本需求，實現了相關功能。一般是在低版本設計時，對未來需求有充分考慮，進行了相關的設計。

3）設計說明

前后端設計及實現不需要修改。

3.3 前端升版模式

1）模式概述

該模式指前端需要設計開發新版本，后端不需要或僅需要很小的改進實現相關業務需求。

在模塊V2版上線時，需要重新配置調試階段功能菜單。

2）適用場景

該模式適用于以下幾種情況：

后端服務能夠支持低版本和高版本的相關業務，低版本和高版本的前端差異很小，高版本頁面布局邏輯有較大調整。

后端服務僅需要較小修改且邏輯獨立清晰，低版本和高版本的前端差異很小，高版本頁面布局邏輯有較大調整。

3）設計說明

前端開發新的版本，調試和運行的功能差異很小，僅需要增加標識區分。

后端服務僅僅需要很小的修改，且業務邏輯清晰簡單。

3.4 前后端升版模式

1）模式概述

該模式指前端、后端都需要設計開發新版本，滿足低版本和高版本的功能需求。

2）適用場景

該模式適用于以下情況：

低版本和高版本的前端差異很小，高版本頁面布局邏輯有較大調整;后端邏輯實現需要較大修改實現相關業務規則。

3）設計說明

前端設計開發新的版本，低版本和高版本的功能差異很小，僅需要增加標識區分。

后端服務需要較大修改，進行重新設計實現。

3.5 新前端模式

1）模式概述

該模式指前端需要設計開發新版本，滿足高版本的功能需求，后端不需要或僅需要很小的改進實現相關業務需求。

2）適用場景

該模式適用于以下情況：

運行和調試的前端頁面布局及邏輯功能差異較大，后端服務僅需要較小修改且邏輯獨立清晰。

3）設計說明

前端需要設計運行的功能界面。

后端服務僅僅需要很小的修改，且業務邏輯清晰簡單。

3.6 前端升版+新后端模式

1）模式概述

該模式指前端需要設計開發新版本，后端調試服務不需要或僅需要很小的改進實現相關業務需求，后端運行需要設計新的服務以實現業務需求。

2）適用場景

該模式適用于以下情況：

低版本和高版本的前端差異較小;低版本和高版本后端業務邏輯差異較大，后端需要修改實現相關業務需求。

3）設計說明

前端開發新的版本，低版本和高版本的功能差異很小，僅需要增加標識區分。

后端低版本服務不需要修改或僅僅需要很小的修改，且業務邏輯清晰簡單。

后端需要新設計服務，以實現高版本業務需求。

4 結束語

本文介紹的基于代碼版本演進模型和軟件迭代設計模式的版本迭代方法，在微服務項目集群的軟件研發項目中具有良好的應用實踐。項目管理者可以根據本文中的代碼版本演進模型進行項目的配置規劃，根據實際項目規模及規范定義相關的人員角色、倉庫、版本分支的規劃。在做系統服務版本設計時，架構師、設計人員再參考設計模式進行設計，合理規劃好系統服務各個版本的功能以及各個功能采用的模式。

參考文獻：

[1] 王磊.微服務架構與實踐[M].北京：電子工業出版社，2016.

[2] 龍新征，彭一明，李若淼.基于微服務框架的信息服務平臺[J].東南大學學報（自然科學版），2017， 47（z1）： 48-52.

[3] Newman S.微服務設計[M]. 崔力強，張駿，譯.北京：人民郵電出版社，2016.

[4] 杜圣東，楊燕，滕飛.交通大數據：一種基于微服務的敏捷處理架構設計[J].大數據，2017，3（3）：53-67.

[5] 李欣，張路，謝冰，等.基于構件的軟件版本管理系統[J].電子學報，2000，28（11）：119-121，131.

[6] 萬志波.協同設計系統中的版本管理技術研究[D].成都：西南交通大學，2005.

[7] Mason M.版本控制之道：使用Subversion[M].陶文，譯.北京：電子工業出版社，2007.

[8] 劉燕秋，勉玉靜，趙文耘.軟件配置管理中版本管理技術研究[J].計算機工程與應用，2003，39（21）：68-71.

[9] 張宇光，王俊杰，胡淵喆，等.面向工作流的Gitlab服務化設計[J].計算機系統應用，2017，26（9）：224-231.

[10] 張宇光.Gitlab 用戶權限管理增強與服務化方法的設計與實現[D].北京：中國科學院大學，2017.

[11] 李勛雄.淺析和家湖南的代碼管理與部署—利用Gitlab，Jenkins實現CI/CD[J].數字化用戶，2019，25（45）： 107-108，110.

[12] 魏海超.基于gitlab的多版本并行開發方法及系統：CN112698815A[P].2021-04-23.

[13] 馮韜，但斌，蘭林春，等.面向大規模定制的產品族結構與配置管理[J].計算機集成制造系統-CIMS，2003，9（3）：210-213.

收稿日期：2022-02-26

作者簡介：汪驥宇（1981—），男，安徽績溪人，高級工程師，碩士研究生，主要研究方向為企業級軟件架構、企業數據治理。