引言

随着计算机应用的广泛和深入发展．软件系统13趋大型和复杂．软件开发往往需要采用团队协作并行开发方式。在这样的规模和开发方式下．软件开发过程中参与开发的人员受到技术水平、主观思维、工作方法等因素影响。难免产生差错。团队协作开发配合不佳也很容易致使软件频繁出现故障和缺陷．软件的开发过程难以控制和管理，导致软件开发周期延长成本增加，软件质量降低．产品风险增加。这种情况下。如何保证软件质量提高软件开发效率是业内人士必须面对的问题。因此．为了保证软件质量．降低开发成本和交付后的维护成本．软件配置管理在软件工程中显得尤为重要。软件配置管理的主要任务是跟踪和控制软件过程中的变化．以使软件在开发过程中任一时间的内容和变化都可以被控制和追溯。借助一些成熟的工具来完成这些工作会有事半功倍的效果．目前被广泛应用的软件配置管理工具有：版本控制系统(如CVS，SVN等)、缺陷跟踪系统(如Bugziila。JIRA等)和测试管理系统(如TestDi．rector等)等。
这些系统单独看来都是很多非常成熟的软件产品．有成熟的权限管理和很高的自动化程度．但当这些系统搭建在一起使用时。它们之间却彼此孤立，各个系统间的信息无法进行共享。例如：缺陷跟踪系统无法获知修正缺陷导致的文件版本的变化，而版本控制系统也无从获知文件版本变化对应的具体缺陷．在实际的开发过程中只能依靠手动在两个系统中分别添加相应的说明以达到可以追溯的目的。
由于这种系统问的信息共享方式高度依赖程序员的自觉．并且依靠手动完成．所以整个开发过程的自动化程度和可靠性在系统问的结合处大大降低．成为整个系统自动化程度和可靠性的短板。对此．本文提出一种整合的软件配置管理环境的搭建方案．可以提高整个软件过程的自动化程度和可靠性，同时能极大提高管理者审核的效率。

1、系统构成
版本控制系统．缺陷跟踪系统和测试管理系统是本方案的核心软件对这些具体软件工具的选择主要考虑三个方面：软件本身功能是否能够满足需求。软件间是否能够整合，是否便于扩展和自定义。另外还需考虑经济成本。据此，本方案的核心软件选择使用完全免费的开源软件。

1．1版本控制系统

版本控制系统选择使用开源版本控制系统Subversion(SVN)．。随着系统的逐渐成熟和第三方软件的不断推陈出新，SVN已经逐步取代CVS成为版本控制系统的主流，成为当下版本控制系统的不二之选。Subversion具有以下突出的优点：
1)全局性的版本编号：版本号是针对整个版本仓库的而不是针对单个文件．可以很方便的根据版本号查询到与该次提交相关的所有文件。更易于提取历史版本；
2)目录的版本控制：准确记录每一次文件改动时整个仓库目录的结构和内容发生的改变．因此可以方便安全的对文件进行移动、删除和重命名。而不必担心文件修改历史轨迹丢失；
3)开源：开放源代码和丰富强大的第三方和客户端软件。同其他系统问有更好的兼容性。其他优势还包括原子性提交．优秀的对二进制和文本文件一致的存储和传输算法．更多的网络支持等等

1．2缺陷追踪系统
缺陷追踪系统选择使用目前最流行的开源缺陷追踪系统Bugzilla。问世12年的Bu ma在各个方面都已日臻成熟，不论是Bug生存期的控制，还是在用户管理、权限管理、统计分析以及邮件通知等各方面都具备强大的功能和可配置的灵活性。由于Subversion和Bugzilla在各自领域的影响力．二者的接13和第三方粘合软件也在不断完善．为系统间的整合提供了有力的保证。

1.3测试管理系统
基于以上的选择和整合的初衷Testopia即测试管理系统的不二之选作为Bugzilla的测试用例扩展应运而生的Testopia，经过不断发展已经成为一款堪比TestDirector的测试管理工具．但相对estDirector昂贵的费用，免费的Testopia足以满足绝大多数的应用需求。同时Testopia作为Bugzila的组件进行安装．同Bugzilla具有先天的整合性：
1)Bugmla中的产品，组件，版本等信息均可在Testopia中被使用：
2)Testopia直接使用Bugzilla的账户。只需另外配置用户的权限即可：
3)Testopia用户可以将Bugzilla中的Bug和测试项目关联起来．从而实现软件工程过程的集中化管理。

2、未经整合的现状

Te8toPia是Bugzilla的扩展组件．因而可以实现缺陷追踪系统和测试管理系统的元缝结合。而Subversion和Bugzina仍然是孤立的．尽管参与开发的人员都可以使用以上系统管理各开发阶段产生的文档、代码、测试和缺陷，但仍然存在以下明显缺点：

安全性方面：
1)难以保证版本仓库中的文件被误操作，发生误操作后难以被发现．后期测试或交付用户后才发现问题往往要付出惨痛的代价：
2)不能保证Bug被指定的人员修正。因为版本系统的用户和缺陷追踪系统的用户是相互独立的．在没有明确权限情况下容易造成多个开发人员修正后产生新的Bug。

可靠性方面：‘
1)由于针对Buz修改的说明靠手工填写实现，当相应文件版本说明有遗漏或差错时．核查人员容易被误导而无法进行有效的核查。为软件质量埋下隐患；
2)版本提交时的说明没有明确针对性。遇到问题回头追溯时并不能给出明确有效的信息。

效率方面：
1)使用不方便：这些系统是开发过程中使用频率很高的工具．而且经常要查看某个缺陷对应的文档代码版本。并进行版本变化的比较。这样不得不在系统问频繁的进行切换，在文件繁多的情况下要消耗许多无谓的精力，长期开发过程中无法保证没有遗漏：
2)管理和核查人员需要同时关注两个系统的变更，尤其是版本控制系统的变化。

3、整合的实现

3．1核心软件
基本核心软件安装在Linux系统下．主要软件包括SVN服务端程序、Apache服务器、mysql数据库，ViewVC(一个基于web的代码仓库浏览工具)，BugziLla，Testopia组件等其他相关配套软件包．各软件的安装配置需参考相关的软件说明文档。

3．2版本控制系统和缺陷追踪系统的粘合
SCMBUG是一款可以用户SVN与Bugzilla间粘合的粘合软件SCMBUG在SVN客户端提交代码时检查提交说明(可以强制要求说明的格式中一定要包含bug号)和用户名(通过帐户映射可以检查该bug是否属于该用户)，通过检查后SCMBUG负责将文件版本变化发送到Bugzilla，使得Bu鲥Ua用户可以在bug页面看到客户端的提交说明和版本变化。安装完SCMBUG后还需要进行很多相关的配置．比如：由于BugziUa的账户是用户的邮箱．如：user@company．com，而SVN的账户是user因此需要在SCMBUG上对两边的账户进行映射，这样两边的权限才能联系起来．为此要修改daemon．conf文件中的mapping_regexes参数，将values值设置为{+)$=>$l＼@company．com}并将使能标志enabted置I相关配置完成后需要使用SCMBUG自带的scmbug_in．stall ue工具打上glue补丁，然后将SCMBUG服务添加到随机启动的项目中即可此时在提交代码时．提交说明中一定要填写对应的bug号，比如提交文件test．c时，提交的目的是修正bug1，则提交说明为”bugl：XXXX”，提交后BuⅡa对应的bug页面将显示提交说明．

3．3为版本的变化增加比对用的超链接
为了方便查看修改前后文件内容的区别．还需要给版本变化加上链接．用户点击链接直接转到ViewVC的版本比较页面查看．以改变现在切换到版本追踪系统找出文件对应版本才能进行比较的低效率方式具体实现有两种方法：修改SCMBUG．使得SCMBUG向BugziUa提交修改说明时，版本变化自动设置为超链接：或修改Bugzilla。使得Bugzilla在接收到说明时．把说明部分的版本转化为超链接。

4、整合后的改善

整合过程不仅解决了前面所提到的整合前的缺点．还提高了既有系统的性能。
对于开发人员来说：
1)修改代码的目的和权限变得明晰(对应的Bugzilla中的Bug号和Bug承担者)：
2)提交修改时只需要在提交版本说明时进行说明，不需要在Bugziua系统中重复操作；
3)提交修改时版本记录由系统自动记录到Bugzilla，无需额外的精力核对，不会出错；
4)在Bug页面中直接可以查看测试用例比较版本，不需要在系统间频繁切换。

对管理和核查人员来说：
1)不需要投入精力关心版本控制系统，只要在收到Bug状态变更时根据Bug中文件版本的变更说明进行审核即可；
2)审核过程只要在点击版本变更的超链接就能马上进行文件的比对．极大的提高了审核效率。

5、结语
至此．整合前的不足都得以解决，整个平台的自动化程度和可靠性大大提高．无疑对于软件质量的提高提供了更有力保障可以根据开发人员的规模选择机架式服务器或者一般的PC机承载这个平台同时由于以上所有软件全部都是开源软件．一方面避免了软件成本和版权纠纷．另一方面可以根据具体的使用需求进行进一步的自定义使得系统更加强大。