SmartChange EE

可扩展组件

案例

基本信息

用户单位：某制造业软件研发企业
用户规模：100人以上
组织过程水平：中等
CMMI评审等级：3级
Subversion使用时间：2年

    合并是并行开发中一个令人头疼的环节，众多的冲突和缺陷均源于此。在缺乏有效的合并跟踪的情况下，会导致众多的问题出现，相关的情况有很多种，以下是一个典型的场景：

    在公司发布产品1.0版本后，该版本分别交付给a,b,c三个客户使用，由于这三个客户的需求各有差异，于是分别从1.0开发主线创建出三天代码线，对应于三个客户，分别为1.0a、1.0b、1.0c，且分别由三个不同的小组维护。这样加上1.0开发主线总共有四条代码线并行。
    此时，1.0a的客户提交了一个缺陷，1.0a的维护团队及时修复了这个缺陷，由于该缺陷是从主代码线1.0带来的，所以该团队及时合并了相关代码。但如果没有有效的合并跟踪机制，1.0b、1.0c两条代码线的维护人员并不知道相关的合并，所以往往会导致如下的问题发生：
   1、重复的发现和修复同一个缺陷。
   2、重复修复后导致额外的合并操作，且往往会导致合并冲突，并且进一步导致处理冲突时产生额外缺陷的潜在风险。
    因此，应该有一个有效的机制来告诉1.0b、1.0c两条代码线的相关人员及时进行相关的同步操作

    由此可见，在持续的并行开发环境下，有效的合并跟踪机制是必不可少的。这种合并跟踪机制概括起来就是：当被跟踪的代码线（大多数情况下为开发主线）发生变更（如提交或合并）时，所有可能受到影响的相关分支/代码线应该被及时跟踪到并告知进行相关的同步操作。

问题解析

    Subversion虽然在其重要升级版本1.5后提供了有限的合并跟踪功能，但该功能相对较弱，尚无法实现上述的跟踪机制。而要实现上述的跟踪机制，一个重要的前提就必须将分支/代码线的所有操作（包括创建、合并及更新等）置于受控状态。

我们的解决方案

    我们的解决方案如下图所示：

    首先，通过系统底层的操作将非受控的分支/代码线操作屏蔽掉，所有代码线操作都必须在特定应用系统（SmartChangeEE）中完成，这样所有的分支/代码线都处于受控状态。如上图所示，分别演示了两种情况：
    第一种情况：缺陷01源于代码线V1.0a，且属于V1.0a的特性部分，而不属于公共应用部分，因此其他代码线不包含该缺陷，所以缺陷修复后无需进行任何同步合并操作。
    第二种情况：缺陷02源于主开发线，且属于公共应用部分，因此在V1.0a后面创建的代码线都应该包含有该缺陷，所以缺陷修复后在向主开发线合并后会自动从主开发线向V1.0b和V1.0c代码线进行代码同步操作，以自动修复这些代码线上存在的Bug

     参见：SmartChange并行开发管理模块