标签：统一 依赖关系 解释 1.5 image 通过 公司 自动 ges
随着公司业务拓展，各业务部门频繁的需求变更，导致系统集成冲突的问题日益突出。
基于SVN版本管理模式，多分支版本并行，分支合并主干交付。多分支开发存在依赖关系且有交付的先后顺序， 导致了合并主干冲突。
业务版本号（4位主干版本号）与SVN版本号的映射关系
+
主干版本号与分支版本号的映射关系
3.1.1业务版本号：提测版本号，即当前的主干版本号，由四位数字组成，如： DUPFJ V1.0.1.1 。
3.1.2 SVN版本号：SVN每次提交操作后自动生成且末位数字+1
3.1.3主干版本号：主干版本号（即业务版本号）与SVN版本号的映射关系
3.1.4分支版本号：不限制，分支可有可无，分支数量无要求
实现方式：
①拉分支记录主干当前业务版本号（同最后一轮转测版本号）
②合主干记录提测主干版本（这里说的版本号统一是业务版本号，业务版
本号映射svn版本）
③回滚版本，根据源码交付操作记录获取当时主干版本号进行回滚版本
方案一：
存在的问题：
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测试，节点增加，造成冲突转嫁更节点增多，且冲突转嫁至质控，质控处理冲突的效率可能会低于研发处理完成的效率）
以上三个问题，均归属于业务风险。
技术风险是可控的风险，可以通过持续交付系统规避或降低，将技术风险控制在可控的低风险范围。
业务风险不可控，业务风险不可预测且随着对业务覆盖率的要求和业务节点的增加，将会导致，风险越来越大，这种业务风险是不可控制的。
业务覆盖：由于节点增多，测试疲劳导致业务覆盖率降低
业务节点：交付节点由一个变成了两个，交付节点出现问题的概率就会增加。
技术风险比业务风险低且可控。
综合分析，方案一更合适。
标签：统一 依赖关系 解释 1.5 image 通过 公司 自动 ges
原文地址：http://www.cnblogs.com/Javame/p/7127413.html
