Truechange 配置管理工具

发表于:2008-02-02来源:作者:点击数: 标签:工具配置管理
配置管理TrueChange和 缺陷 追踪TrueTrack 什么是配置管理 软件配置管理是一控制软件系统演变的学科,“协调软件 开发 使得混乱减到最小的技术叫做软件配置管理,它是一种标识、组织和控制修改的技术,目的是使错误达到最小并最有效地提高生产效率。” 为什

配置管理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或升级一个软件版本时,人们通常要对多个文件进行修改。基于文件的配置管理模型意味着:对任何一个软件项目的变更实际上被存为许多文件的变更。在这些配置管理产品中,没有将每个文件的变更联系到更高层次的变更的机制。
然而,正如下面要指出的,文件增量技术也有许多内在的限制,这就是说应用文件增量技术的配置管理工具不是解决配置管理中困难的最优工具。文件增量技术事实上描述了不同版本的文件之间的每行的差异,这就意味着文件增量将对它所应用的版本有很强的依赖性,也就是说,把一个文件增量应用到不同的文件版本几乎是不可能的。
很难移除历史的变更:
如下图所示:

如果一个文件增量需要被移除,可能这个软件版本要返工了,下面的图例表示了这种情况
如图示,这和配置管理中的真实文件增量是相同的,唯一的可以利用的修改历史增量的机制就是拿掉这个文件变更,用一个新的文件变更来替代从而组成新的文件版本,

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

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

这种文件增量的内在限制就是文件增量是依赖于某个特定的文件版本的,这就使得搬迁文件增量十分困难。解决的办法就是逐行比较变体文件,这是一个很困难的工作,并且容易出现人们不易察觉的错误。
管理并行版本的困难:
一个软件项目通常会包含很多文件,可能在这有很多文件中包含了成千上万的变更,当管理包含很多文件的软件版本时,单个文件里的文件增量形成了对它的限制,所以,当我们谈到整个软件项目时,最基本的配置管理需求遇到了前所未有的挑战。
基于文件的配置管理工具不可用的功能有:
在同一个项目中的两个并行版本上搬迁文件变更
移除曾经对某个历史文件所做的改变
通过所有的并行版本来管理所有对文件做的变更
除去这些限制,基于文件的配置管理模型能够适应管理文件变更,所有用文件增量模型的配置管理产品。都是支持版本管理的主要功能的,然而,意味着一些任务很难实施。这就使得用户不得不按照他们所使用的 配置管理工具来修改他们的软件实施过程。

原文转自:http://www.ltesting.net