【IT168 技术文章】

    1、引子

    在象NT或UNIX这样的操作系统环境中，一个文件可以看作是位于巨大的文件空间中的一个点。这个点是随时间而流逝的--当你修改文件，产生了新的版本时，前一个版本就被覆盖了。

    在很多情况下，我们是需要操作系统的这种性质的，例如它能避免文件垃圾的积累。 但对于软件开发来讲，这种易失性却会带来很明显的问题：软件开发过程中，经常需要保存以前的东西，对同一个文件或工程，经常有多个版本。这时，现有的操作系统结构和软件开发的实际需要之间，就会产生一些问题，一些冲突。例如，由于没有版本的概念，使得没有办法恢复以前的工作。有编程经验的人，可能都遇到过这样的情况：在头脑不太清醒的时候，修改了程序的算法，后来却发现算法是错误的。这时不得不做一件很痛苦的事：设法恢复修改以前的东西--这个过程既evelop] 枯燥又浪费时间。所以，没有版本的维护，给软件开发带来很大的问题。

    2、软件配置管理

    软件配置管理，缩写为SCM（Software Configuration Management），可能比“版本控制”听起来要生疏。实际上，软件配置管理的首要问题就是：怎样来进行版本控制。

    2.1版本控制

    首先要把原来（文件作为）离散的点的存在方式变成（不同版本的）链的方式，把每个版本都保存起来。一种原始的实现方式是建立目录：每天建立新的目录，保存文件的备份--这是没有办法的办法，总比让文件丢掉强。但是你往往会发现，建立很多目录后，面临磁盘空间不够的问题。解决的方法是删掉某个时间以前的虽然这样做不会导致出现大的问题，但是需要手工进行删除。另外，由于文件之间是相互独立的，在小组的工作方式下就会带来麻烦，如果某一天，组里一个人说：“23日更正了一个BUG”，那么必须对23日之前的所有子目录下的内容进行修改， 才能避免同样的BUG再次出现。而且，在实际开发中，23日更正了BUG后，24日，25日的程序中同样的BUG可能改了，也可能没改。如果下面的开发工作是依据最新的版本，则原来的修改工作就被淹没了。 所以，一般需要采用一些进行版本控制的工具。在国内，使用最多的可能就是微软evelop]的Studio Package中带的VSS。其它常用的工具包括PVCS和Rational公司的ClearCase等。尽管VSS的市场占有率可能更高，但PVCS应该是在国内最有名的。这些工具各有所长，但都能实现将一些点组织成链的基本功能。这样，程序员能够很可以放心地对程序进行修改。需要恢复时再Roll Back就可以了。

    2.2配置

    除版本控制外，程序员还会遇到其它的问题。最普遍的一种就是配置问题。现在国内对SCM的重视程度越来越高。ROSE是目前很用得很普遍的工具。不过根据我们在做市场做销售过程中获得的概念，用户接受ClearCase工具的速度比接受ROSE快。因为ClearCase解决的问题是令用户明显地感觉到疼痛的问题，所以他们很快认为ClearCase是个好东西。而ROSE由于有OO等较复杂的技术问题搀杂在其中，导致接受的过程反倒慢一些。对配置管理问题比较重视的，主要是象华为，阿尔派这样比较成功的大型企业。小的企业没有建立起配置软件的概念，系统攒出来后，并不负责维护。对于大型公司，则要提供维护服务-对于用户抱怨的某个版本的问题，要在限定的时间内进行解决。如果没有版本维护的工具支持，完成这类工作几乎是不可能的，因为以前版本的代码可能已经无处找了，以前的开发人员也可能已经离开公司了。在大型企业的软件开发中，配置问题非常重要和复杂。不同的版本，不同的操作系统平台，以及（对于系统集成商来说）不同的用户，都分别对应着配置空间一个新的维度。维度的增加，软evelop]使得组合爆炸非常厉害。采用配置工具是解决这一问题的可行方法。前面提到，目前每个文件的不同版本已经形成一条链。而一个和项目相关的库，则相当于一个森林。形象一点讲，每条链展现了文件的历史--它不断长大和发展着。目前的存储机制是把整个状态录制下来，并定义一些配置--如本文件的这个版本和另外的文件的另一个版本构成一个配置，每种配置相当于用一个相机拍摄下的空间的某一断面，历史长河中一瞬间。这样的一些配置，如果能不断进行保存，则能解决前面提到的找到旧版本程序源代码的问题。

    2.3分支

    在并行开发中。一个项目几个人做。当每个人都想对文件进行修改时，一般采用分别拷贝，修改后再拷回去的方法。这导致的问题是，当两个人分别进行了拷贝和修改后，如果甲刚把修改后的文件拷贝回去，乙又把自己修改的结果拷回，则甲的工作就被覆盖了。多人合作中，经常由于这些配合管理问题，影响效率，浪费工作。一种比较严重的情况是，系统集成项目，模块按定义已经开发好，却无法装配使其运转起来。

    为解决这种问题，配置管理工具普遍具有的一种功能是：加分支（Branching）在单链结构中，只有该链最底下一个（新版本）生长点。所有的配置管理都会采用增量存储的方式来保存不同版本。增量存储的一个问题是，新版本不能从链的中间增长。这决定了同一时刻只有能一个人能够写文件。唯一的解决方案是，evelop]建立一个分支，几个人可以在不同的分支上进行修改。如果并发修改只有分支(Branching)，没有汇合(Merging)，则这种技术是没有意义的。汇合的一种最笨的方法是，程序员同时打开两个文件，手工比较它们的差别，并将改动进行合并。一般的工具是利用计算机实现比较基本简单的工作，高智能的工作也要人的介入。该工具将帮助程序员查找不同点，提供修改的选项。这种工具带来的好处是，可以并行开发。显著提高了工作效率。

    2.4其它问题

    除了上述基本问题，另外还有一些问题。如Build管理(Build Management)。这是在在配置之上提供的一个功能。工具帮助记录和编译相关的信息，如开关项，链接库等。在必要的时候恢复这些信息。

    功能更强的配置工具还提供过程控制(Process Control)，是在配置管理之上增加的一些控制机制。每个企业有自己的一些文化方面的或其它的特殊规定--如在Checkin 的时候需要提交一个文件，Checkout时进行身份验证等。这方面的工具有很多很强的定制性。(吴穹启动装在笔记本上的ClearCase，边演示边讲解）对于PVCS和VSS，工作空间 (WorkSpace) 和保存空间 (SavingSpace) 是分离的。 Checkin的时候系统会询问，是否把在工作空间中的内容删除。而在ClearCase中，evelop] 两个空间是统一的。且ClearCase提供更强的安全性。它在文件系统之上搭了一个 MultiVersion System，使底层对用户屏蔽起来。用户面对的是称为版本对象库（VOB）的虚空间。只有在Checkout后才能对文件进行修改。且在Checkin状态下，文件的属性是无法修改的。在VSS中，Checkin状态下本地工作空间的文件虽然是只读属性的，但是可以对文件的属性进行修改，从而避开VSS的安全控制机制。 创建VOB的过程非常简单。提供名称和存储位置就可以了。在创建VOB之后，面对的另一个概念是视图（View）。 通过视图用户可以只看感兴趣的东西。建立VIEW时有两种方式供选择：Dynamic方式下，库中的任何一个改变都能反映到视图上。Snapshot方式则在捕获当前状态后，离线工作。创建视图时同样需要提供名称和存储地点。除此之外，视图被映射成一个盘符。程序员控制视图，感觉就象对一个磁盘进行操作。

    如果看版本，可以通过可视化方式。查看版本信息，修改信息。也可以通过命令行方式直接编辑配置文件。另外，ClearCase还提供比较两个版本之间的区别的功能。假设已经做了一个版本，需要提供一个标签，标识该版本。在VSS中，采用加一个字符串的方式，但是不同程序员采用的名称可能是不统一的（如，同样是第一个版本，有人称为Version1，有人选择Release1等）。在ClearCase中提供类型机制。首先要建立一个标签类型。然后将该标签赋给相应的版本。在ClearCase中，几乎所有的东西都有类型。如建立分支也要首先创建分支类型。Checkin的时候系统会询问，是否把在工作空间中的内容删除。而在ClearCase中，evelop]

    3、 变更请求管理

    变更请求管理，缩写为CRM (Change Request Management)，Rational公司相应的产品叫ClearQuery。它能辅助各部门之间的工作协调。和SCM比，CRM是相对小型的工具。软件公司利用NOTES就可以自己搭出这样的工具。但该工具却又是非常重要的。ClearCase帮助提高开发人员的效率，而ClearQuery则能提高团队工作的效率。现在的趋势是由C/S的体系结构转换到基于WEB的方式。通过网页提交错误报告等信息。 (启动笔记本中的Clearquery，边演示操作边讲解。首先启动SQL Server。随后打开ClearQuery。）

    假设是个平常用户。在使用软件产品时发现了一个错误，那么使用报告Defects的用户界面，键入用户名，表明身份后，填写表格，报告发现了一个如何如何的问题，最后提交到服务器上.如果是项目管理人员，启动管理的界面，可以查看共有哪些错误报告，然后，分配给相应的程序员解决。

    对于开发人员，则可以通过对应的界面查看当天分配的任务，要解决的问题是什么上层管理者还可以查看当前产品的出错程度，职员的工作状态，是否需要招人。 工程师太累了还是太轻松了，等等。信息能够以图表的形式显示。实际上，这已不是一个狭义上的变更请求管理工具，已经介入了工作流管理。华为已经在做类似的工具。很多外国公司也在使用这类工具。该工具真正难做的在于可定制性。可以对管理流程从头定制，定义状态的转换，要发生哪些行为，谁来做，等等。它可以帮助提供严格的权限控制--如要求测试经理对报告的错误进行复查。特定于公司内部的权限，表格，查询都可以定做。

    如果用NOTES自己搭建这样的工具，好处是前期投入比较低，但需要大量的维护工作--用了一段时间后，会认为工具太僵化，要增加一些灵活性。而要进行改变，涉及到 编程。这就可能引入错误，而这种重要的工具，一旦出了问题，会影响到整个开发队伍。 因此，在项目规模较大的情况下，适宜采用成熟的管理工具。（继续演示ClearQuery）定制的过程有现成的模板可以利用，也可以完全自己做。 ClearQuery目前在国内使用还不普遍。国内客户还要有一个接受的过程。