一种基于版本演进模型和迭代设计模式的软件版本迭代方法

汪骥宇 陈武 张千秋 胡芳

摘要：在采用微服务架构设计软件时，随着软件规模的增大，需要管理的微服务越来越多，微服务版本迭代也越来越多，对微服务的版本设计与管理越来越困难。为解决该问题，文章提出了基于版本演进模型和迭代设计模式的版本迭代方法，方法包括一个版本演进模型和一种迭代设计模式。版本演进模型是一个管理模型，包括软件版本计划管理、主仓库、预发仓库、开发仓库、开发人员仓库、紧急修复仓库管理内容，实现软件服务全生命管理。迭代设计模式中介绍微服务版本迭代的设计模式，指导设计人员进行软件服务的版本设计。

关键词：微服务;版本演进模型;迭代设计模式

中图分类号：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—），男，安徽绩溪人，高级工程师，硕士研究生，主要研究方向为企业级软件架构、企业数据治理。