首页 > 代码库 > SVN多项目并行版本管理解决方案

SVN多项目并行版本管理解决方案

技术分享

1、背景

随着公司业务拓展,各业务部门频繁的需求变更,导致系统集成冲突的问题日益突出。

2、现状

基于SVN版本管理模式,多分支版本并行,分支合并主干交付。多分支开发存在依赖关系且有交付的先后顺序, 导致了合并主干冲突。

3、解决方案

业务版本号(4位主干版本号)与SVN版本号的映射关系

+

主干版本号与分支版本号的映射关系

3.1名词解释:

3.1.1业务版本号:提测版本号,即当前的主干版本号,由四位数字组成,如: DUPFJ V1.0.1.1 。

3.1.2 SVN版本号:SVN每次提交操作后自动生成且末位数字+1

 

3.1.3主干版本号:主干版本号(即业务版本号)与SVN版本号的映射关系

3.1.4分支版本号:不限制,分支可有可无,分支数量无要求

3.1.5 SVN实现方式

实现方式:

    ①拉分支记录主干当前业务版本号(同最后一轮转测版本号)

②合主干记录提测主干版本(这里说的版本号统一是业务版本号,业务版

本号映射svn版本)

③回滚版本,根据源码交付操作记录获取当时主干版本号进行回滚版本

3.2解决方案

方案一:

 技术分享

 

存在的问题:

1、  主干回滚频率高;

2、  技术能力(SVN操作、冲突解决的能力)

3、  项目编排(先后顺序、依赖关系)

以上三个问题,均归属于技术风险。

问题1解决方案:SVN合并主干规范化。通过规范SVN合主干描述中的业务版本号,确保频繁回滚主干的规范性。

 技术分享

问题2解决方案:通过持续交付系统实现对SVN的自动化操作。

根据持续交付系统的SVN操作记录,实现多项目并行交付。

 技术分享

 

持续交付系统会记录SVN上每次的操作记录(log信息),记录项目、主干版本号、分支版本号和归档版本号的映射关系。

 技术分享

 

合并主干时:

待提测主干版本号末位-1是否与映射关系记录中当前主干版本号一致;

1、  一致:直接合并主干;

2、  不一致:

1)主干版本号末位-1在映射关系记录中有记录,但并不是当前主干版本号时

实现方式:先回滚再合并主干

①先回滚至主干版本号末位-1的主干版本;

②再合并主干;

示例:待测主干版本号2.0.2.4,末位-1为2.0.2.3,在映射关系记录中有记录,但并不是当前主干版本号

①先回滚至2.0.2.3

②回滚成功后再合并主干

2)主干版本号末位-1在映射关系记录中没有记录时

实现方式:先回滚再合并主干

①主干版本号前三位为分支版本号,通过分支版本号找到与最初主干版本号的映射关系(即第一个分支与主干版本号的映射关系),先回滚至该主干版本;

②再合并主干;

示例:待测主干版本号2.0.2.1,末位-1为2.0.2.0,在映射关系记录中没有记录

①主干版本号2.0.2.1,由此可以确定分支版本号为2.0.2,分支版本号可以确定该分支与最初主干版本号2.0.1.3存在映射关系。先回滚至最初主干版本号2.0.1.3。

②回滚成功后再合并主干;

问题3解决方案:通过项目上线的优先级解决。优先级高的项目优先编排,优先合主干。

 

方案二

 技术分享

 

存在的问题:

1、  拉长了周期、增加了节点

2、  重复的测试内容(分支测试+合主干测试)

3、  冲突转嫁(分支1和分支1测试,节点增加,造成冲突转嫁更节点增多,且冲突转嫁至质控,质控处理冲突的效率可能会低于研发处理完成的效率)

以上三个问题,均归属于业务风险。

4 总结

技术风险是可控的风险,可以通过持续交付系统规避或降低,将技术风险控制在可控的低风险范围。

业务风险不可控,业务风险不可预测且随着对业务覆盖率的要求和业务节点的增加,将会导致,风险越来越大,这种业务风险是不可控制的。

业务覆盖:由于节点增多,测试疲劳导致业务覆盖率降低

业务节点:交付节点由一个变成了两个,交付节点出现问题的概率就会增加。

技术风险比业务风险低且可控。

综合分析,方案一更合适。

 

SVN多项目并行版本管理解决方案