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多项目并行版本管理解决方案