【IT168 技术文章】

    配置管理TrueChange和缺陷追踪TrueTrack
    什么是配置管理
    软件配置管理是一控制软件系统演变的学科，“协调软件开发使得混乱减到最小的技术叫做软件配置管理，它是一种标识、组织和控制修改的技术，目的是使错误达到最小并最有效地提高生产效率。”
    为什么要配置管理
    对于任何一个软件组织（企业）来说，开发出满足用户需求的、高质量的软件产品是其追求的目标。而要实现这一目标的关键是建立起一个稳定、可控、可重用的软件过程（Software Process）。因为某一软件产品的成败可能维系于关键技术的突破和创新；但对于软件组织而言，要想永葆竞争优势并不断取得成功，那就必须不断地改进它的软件过程。要进行软件过程改进（Software Process Improvement）就需要有明确的、量化的对现状的分析和对未来的预期，这些数据来源于对软件过程的度量，而进行度量的前提和基础就是软件配置管理。
    软件配置管理的解决方案涉及面很广，将影响软件开发环境、软件过程模型、配置管理系统的使用者、软件产品的质量和用户的组织机构。软件组织应该提出不同层次的配置管理视角，这些层次包括：公司级、项目级、程序员级和应用级。
    TrueChange配置管理平台
    要知道介绍Truechange的发展历程，我们必须从SMDS介绍，SMD花了1989到1995年之间的时间开发第一个商业基于变更的配置管理工具的核心技术。1995年4月这项技术被收购，并得到稳定和巩固，新的公司更名为TRUE Software。1995年12月发布ADC/Pro，1997年此软件更名为TRUEchange并且加入问题追踪工具TRUEtrack, 1999年软件测试行业著名公司收购了TRUEchange和TRUEtrack，从此McCabe公司的产品线从配置管理更加到软件测试与质量管理更加完整。
    软件配置管理的技术体系有两种：一是基于文件的配置管理，起源于UNIX和开放式系统，在这种体系下任何东西都是以文件的形式体现的，配置管理也就是对文件的管理。另一种是基于变更的配置管理，起源于大型计算机社区，配置管理的不仅仅是文件，更要管理变更。
    基于文件的配置管理:
    配置管理是管理文件版本的，乍一看，这似乎是一个没有什么问题。如果我们追溯到最初的应用于UNIX平台配置管理的解决方案，可以看出，文件也包括程序、数据、目录甚至操作系统本身。所以说，我们认为配置管理不但要管理文件还要管理对文件的变更。
    当管理一个文件在升级的许多版本时，我们可以清楚的看出为每个文件版本都保存一个完整的内容是非常浪费资源的，因为版本之间一定会有许多公用的东西，这就导致了文件增量技术的出现：文件增量技术是只保存版本之间的差异部分的一种技术。
     

    一些配置管理工具认为最新的版本就是：把基础版本或历史版本加上文件增量，这会改善系统的性能，实际上，如果只允许最近的版本是所有文件增量加上基础版本的话，将会使得系统的性能下降。现在的配置管理工具都是基于文件的，通常会采用文件增量技术。
    通常当我们修改一个软件版本中的BUG或升级一个软件版本时，人们通常要对多个文件进行修改。基于文件的配置管理模型意味着：对任何一个软件项目的变更实际上被存为许多文件的变更。在这些配置管理产品中，没有将每个文件的变更联系到更高层次的变更的机制。
    然而，正如下面要指出的，文件增量技术也有许多内在的限制，这就是说应用文件增量技术的配置管理工具不是解决配置管理中困难的最优工具。文件增量技术事实上描述了不同版本的文件之间的每行的差异，这就意味着文件增量将对它所应用的版本有很强的依赖性，也就是说，把一个文件增量应用到不同的文件版本几乎是不可能的。
    很难移除历史的变更：
    如下图所示：
        
    
    如果一个文件增量需要被移除，可能这个软件版本要返工了，下面的图例表示了这种情况
    如图示，这和配置管理中的真实文件增量是相同的，唯一的可以利用的修改历史增量的机制就是拿掉这个文件变更，用一个新的文件变更来替代从而组成新的文件版本，
    

    在并行的软件版本中迁移文件变更的困难：
    假如我们现在在维护同一文件的两个不同版本，在某个特定的版本里最初只有一个文件，从那里开始把不同的文件变更应用到分别应用到这两个分支，其结果是应用了不同的文件变更的不同文件变体，但他们共用一个文件母体，下面的图表示了这种情况：
    

    现在让我们考虑把其中的一个文件增量搬到另外一个文件分支上去，或者是说把把一个文件增量应用到这一文件的其他分支的不同版本上，用图表示如下：
    

    这种文件增量的内在限制就是文件增量是依赖于某个特定的文件版本的，这就使得搬迁文件增量十分困难。解决的办法就是逐行比较变体文件，这是一个很困难的工作，并且容易出现人们不易察觉的错误。
    管理并行版本的困难：
    一个软件项目通常会包含很多文件，可能在这有很多文件中包含了成千上万的变更，当管理包含很多文件的软件版本时，单个文件里的文件增量形成了对它的限制，所以，当我们谈到整个软件项目时，最基本的配置管理需求遇到了前所未有的挑战。
    基于文件的配置管理工具不可用的功能有：
    在同一个项目中的两个并行版本上搬迁文件变更
    移除曾经对某个历史文件所做的改变
    通过所有的并行版本来管理所有对文件做的变更
    除去这些限制，基于文件的配置管理模型能够适应管理文件变更，所有用文件增量模型的配置管理产品。都是支持版本管理的主要功能的，然而，意味着一些任务很难实施。这就使得用户不得不按照他们所使用的 配置管理工具来修改他们的软件实施过程。
    基于变更的配置管理－TRUEchange:
    McCabe TrueChange 是唯一的一个不用基于文件的文件增量技术的配置管理工具。McCabe TrueChange 使用基于变更的技术，即把软件的变更作为一个单独的实体来管理，即使它包含了很多文件的很多改变，这些文件的变更不和某一个特定的文件版本有关。它独特的基于变更的技术意味着TrueChange可以适应管理并行开发的需要，可以在并行版本不同的文件中变体迁移单个文件的变更，并且当变更需要重现是可以轻松实现快速开发。
    TrueChange不使用文件增量技术来存储变更，而是把所涉及的文件变更组成一个叫ChangeSet的文件。ChangeSet封装了软件中对所有涉及到的文件的变更。
    ChangeSet是管理变更过程的一个非常自然的过程，这并不是它独特的功能，因为一些基于文件的管理工具也可以支持多个文件的变更的管理。TrueChange的主要的益处在于这些变更被存储时不和某一个特定的文件版本相关联.
    每次TrueChange用户为了修改文件都要先从库中取出文件，这个过程会自动创建新的开放的ChangeSet，再这个ChangeSet里用户可添加或删除文件。每个ChangeSet都有一个唯一的标志并有一个描述区域来说明改变的具体内容。这个从ChangeSet里添加或删除文件的能力可以很清楚的记录开发者或用户的一切活动。
    一旦用户认为修改结束，他们就可以存入ChangeSet，这个ChangeSet将会被提交到库里，存储到用户工作的项目版本里面。
    把所有的变更都应用到同一个基础表中，使得应用这些变更到并行版本上时变的非常轻松。
    TrueChange的库
    TrueChange用一个非常强大的高性能的数据库来存储配置管理下文件的修订版本和一些组件，这个数据库用对象数据库存储变更管理下的信息和版本控制的所有信息。这包括工程里的信息、版本树和应用与每个版本的ChangeSet。
    强大的分支
    从以上这些差别中可以看出，TrueChange用户可以轻松实现读并行版本的管理。在TrueChange里创建并行版本是很快的，因为没有需要移动、复制的文件或文件增量。也不需要另外的硬盘空间。
    这就使得分支应用频繁的的并行管理活动中，与基于文件的配置管理通过管理一个版本的许多并行活动对比形成了鲜明的特色。一个主要原因是基于文件的配置管理通常是认为基础文件作为最新版本。结果，创建分支时就导致复制了这个项目中的所有文件。不但需要双倍的硬盘空间，还须花费更多的时间。
    突的解决方法—在并行分支中同一文件被做了不同的改变，用TrueChange会变的很直截了当，用户只须选择哪个是正确的，另外，用户也可以修改行或其余文件来解决冲突，创建一个新的结果，TrueChange把变更存储在过程中，当别的变更应用与同一行时解决的结果将被调用。