| 摘要 本文的重点是介绍如何应用软件配置管理工具软件进行大规模软件的软件配置管理，在软件开发实施过程中依据项目进度和要求，适时调整软件配置管理系统，保证软件开发有序进行，保证开发过程版本和最终发布版本正确、统一。 一、前言 对于一个软件企业，开发出满足用户需求的、高质量的软件产品是其追求的目标，而实现这一目标的关键是建立起一个稳定、可控、可重用的软件开发过程。软件企业要想永葆竞争优势就必须不断地改进它的软件开发过程，而要进行软件开发过程改进就需要有明确的、量化的对现状的分析和对未来的预期，这些数据来源于对软件过程的度量，而进行度量的前提和基础就是软件配置管理。所以，软件配置管理工作是以整个软件过程的改进为目标，是为软件项目管理和软件工程的其他领域打好基础，以便于稳步推进整个软件企业的能力成熟度。而做好软件配置管理是迈向软件开发规范化管理的第一步。 对于中小型软件开发，软件配置管理的作用不是很明显，但对大型软件开发，由于开发人员众多，程序量大，系统复杂，软件配置管理至关重要。 软件配置管理对于软件开发管理是如此重要，它的主要思想和具体内容在于版本控制。版本控制是软件配置管理的核心思想之一，是指对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理。版本控制最主要的功能就是追踪文件的变更。它将什么时候、什么人更改了文件的什么内容等信息忠实地记录下来。每一次文件的改变，文件的版本号都将增加。除了记录版本变更外，版本控制的另一个重要功能是并行开发。软件开发往往是多人协同作战，版本控制可以有效地解决版本的同步以及不同开发者之间的开发通讯问题，提高协同开发的效率。并行开发中最常见的不同版本软件的Bug修正问题，就可以通过版本控制中分支与合并的方法有效地解决。 二、大型软件系统 大型一体化系统软件是为了满足石油勘探开发对地震数据处理与解释日益增长的需要，而开发的大型处理、解释一体化系统，该系统由系统平台和应用系统组成，系统平台包括数据平台、交互框架平台、通用显示工具、可视化显示平台。在这个平台上构建处理系统、解释系统和一体化应用系统。项目计划在两年内完成，预计程序行数400万以上、开发人员200余人。 经验表明，软件规模越大生产率越低。而且随着软件规模增大，软件开发成功率也越低，在我们国家，软件业还没有脱离手工作坊的方式。如此大规模的软件开发，已往手工作坊式的管理方式要改变，软件配置管理要创新。与其他的一些软件工程活动不一样，软件配置管理的对象——（软件）配置项，它们不仅是大量人力物力投入的结晶，更是开发经验的积累，是软件组织最宝贵的财富。 软件配置管理贯穿于软件开发活动的始终，覆盖了开发活动的各个环节，它的重要作用之一就是要全面的管理保存各个配置项，监控各配置项的状态，并向项目经理及项目长提交配置报告。配置管理工作更强调工具的支持，缺乏良好的配置管理工具的话，要做好配置管理的实施会非常困难。软件配置管理是一项十分繁琐的工作，同时又和整个软件的开发活动紧密地联系在一起，为使软件开发能够始终处于受控之中，就必须建立一套体现软件工程特点的配置管理体系，并依据体系要求选用软件配置管理工具。 三、软件配置管理工具 Firefly是Hansky公司软件开发管理套件中的重要组件。Firefly可以对大型软件开发的程序代码和相关文档进行管理，具有以下突出的特点： 1、本地工作区（Local Workspace） Local Workspace存储从服务器上下载的一个分支的下的文件，开发人员在工作时首先要从服务器上将最新修改的项目文件下载到本地工作区，然后才能对项目文件进行编辑、编译、调试等工作。有了Local Workspace，可以保持本地的工作文件和服务器上的工作文件的同步。同时，还可以比较本地工作区文件与服务器文件的不同，在每次下载和上传时不必将所有的项目文件都传输一遍，从而提高了工作的效率。 2、标签（Label） Label采用索引技术提高了操作效率，通过下载Lable的功能为编译、测试提供了便利。 Firefly支持并行/串行两种开发模式，并且提供向导来检验和解决文件的冲突，使得团队的开发快速、便捷而且高效。 4、分支 在Firefly中可以方便的建立项目的分支，可以在主分支上建立分支，也可以在次分支上建立分支，还可以在Label的基础上建立分支；建立分支的时候可以选择父分支的一部分文件。 4、变更集 Firefly将每一次工作区的检入都视作一个变更集，每一个变更集都作为项目分支的历史被保存下来，管理人员可以通过WEB界面方便的查询分支的历史。 利用原子事务的概念，将一个包含多个文件改变的入库操作作为一个事务（Transaction）来对待，全部文件的提交只有成功或者不成功两种情况，没有中间状态（如一部分成功提交，而另一部分提交失败的状态）。这样能够处理一些操作过程中的异常情况，比如提交过程中网络中断等，保证软件系统的一致性，防止其他开发人员取到错误的代码而编译、运行失败。 通过Delta操作支持本地版本的记录。在某一工作区中，修改了一个文件，然后通Delta操作，可以在本地记录下一个新的版本。提交到服务器上后，其他人也可以访问这一版本。 Firefly采取了类似于NTFS的权限控制体系，不仅能够控制项目分支一级的权限，还可以深入到目录/文件一级进行权限设定，文件的权限缺省从目录继承，还可以手工对特定文件的权限进行调整；并且可以细分权限的等级。这种权限体系可以保证项目所涉及到的开发工作都处于受控的状态下，从而保障项目不受干扰，能够顺利开发。 四、建立配置管理体系 1、管理层次 依据配置管理系统功能特性，结合我们实际情况和需要，建立自己的管理体系。以往，我们已经成功地开发了其他大中型软件，但配置管理体系很不完善，一些主要配置项（源代码和程序文档）是靠手工管理，由于人员流动性大，又没有统一的配置管理体系，开发活动不能受到有效的控制，不能形成团队财富的积累。有人对配置管理是什么都不清楚，对配置管理系统的使用在思想上不容易接受，认为使用配置管理系统进行程序版本控制使开发活动受到了限制，给开发增加了工作量。特别是这次超大规模软件系统的开发，时间紧，任务重，如果配置管理系统使用不当影响项目进度或造成源程序丢失，会给开发带来巨大损失，后果不堪设想。 依据两层管理模式，配置管理和版本控制主要在项目级和子项目级配置管理员中使用。从一体化系统的结构来说，尽管该系统庞大，包括许多子系统，但是，最终要集成一个系统，而且管理模式决定了版本控制是在项目开发到一定阶段，形成初步系统模型时纳入版本控制。因此在Firefly服务器上创建一个程序代码库，用来存储初步集成的源代码。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。 创建一个代码存储库，是为了便于统一管理，但是如何让开发人员根据任务分工的不同而获得对相应配置项（源代码）的操作许可，而对于其他源代码不能操作。为此，利用Firefly提供的文件级访问权限设置，对不同目录进行用户权限设置，只有对该目录具有读写权限的用户才能对其进行操作，为子系统配置管理员授权一个文件目录，如图２权限设置图中src/ap目录授权给smq用户。
图2 权限设置 4、分支的划分 · 集成分支 为了系统集成测试需要，创建集成分支，并对该分支进行了不同子项目的权限控制，各子项目必须将开发成果纳入到该分支，凡是对纳入到该分支的配置项进行的任何变更，都必须首先从该分支获得，变更后再上传到该分支。软件的集成测试工作在这一分支中进行。项目级配置管理员拥有对该集成分支的管理和读写权限，子项目级配置管理员只有对指定的目录有读写权限。（图3分支图） 主干分支对应的是整个软件开发组织的发布分支。各个子项目在现阶段的任务完成后，将可以发布的版本归并到该分支上，由该分支产生发布版本，对每次的发布基线和相关资料，以该分支上的版本为准。该分支的管理工作由项目级配置管理员负责。（图4分支及标签）
· 产品基线 当一个开发里程碑结束，或有重大事件发生时，利用配置管理系统提供的标签功能，对集成分支和主干分支进行标记，该标记作为产品基线，可以按标记进行版本发布和再现（图4分支及标签）。 把相关配置项纳入集中的存储库、为不同目的建立了不同分支后，按照初始设定的管理层次，子项目级配置管理员遵照“检出/检入”的工作模式对配置项进行修改，就要为每位子项目级配置管理员设定本地工作区，对所授权的目录进行的任何变更都要在本地工作区进行。 开发人员根据项目要求在自己的私有工作区中对配置项进行修改和测试活动，私有工作区可以是CVS版本控制软件工作空间或其他，自己的修改活动不会受到他人的影响，也不会影响到其他开发人员，修改和测试后的配置项提交给子系统配置管理员，由子项目级配置管理员上传到集成分支。 五、逐步完善分支创建方式 1、依据开发需要，创建平台分支 由管理层次决定的分支是一个主分支一个集成分支，但随着开发活动的深入，系统平台开发和应用开发之间出现互相牵制问题，平台程序变更后在没有与应用程序联调之前，会影响到应用程序的开发，严重时会使应用程序开发工作无法正常进行，为了查找原因，有时需要花上一两天时间，影响了开发进度。鉴于这种情况，新创建了系统平台分支，系统平台子项目组在该分支开发集成，待测试通过并与应用联调后再利用分支归并功能，将程序归并到集成分支，既达到了程序控制的目的，又不影响开发进度，有效的提高了开发效率。这一分支方式说明了通过科学管理可以出效率。 平台分支和集成分支应用一段时间后，又出现了新的问题，平台的变更，需要通过应用程序进行测试。但是，系统平台分支上的应用程序不能时时更新，除非将集成分支的应用合并到平台分支，这样给管理带来许多麻烦，为了解决该问题，利用FireflyV3.0版本中提供的链接功能，在系统分支上创建了链接，链接到集成分支的应用部分，这样，平台分支可以随时得到应用系统变更的文件，大大方便了测试版本的制作。（图5链接点）。 3、为发布产品，启用主干分支 在项目开发阶段基本结束，进入产品发布阶段后，除了建立产品基线外，启用了主干分支为发布分支，集成分支上测试通过的程序，及时合并到发布分支制作发布版本。在产品发布初期，用户和试生产发现问题比较多，程序变更频繁，每周要集成一个新版本，为了标示不同时间编译的版本，除了版本号之外，附加了BuildNumber来标示，如图4所示的标签。 六、依据测试阶段，集成软件版本 从软件工程化和保证产品质量出发，软件测试采用三级测试方式：单元测试、集成测试和生产性测试（试生产），由于项目开发时间紧，不能一级测试结束，再开始下一级测试，而均采用滚动开发测试方式进行，多数情况下是同时进行，这给版本控制和集成带来很大困难，为此，建立了三种集成环境。三个版本的版本控制和集成是通过分支、测试基线、分支合并来完成。 单元测试由开发人员在相对稳定的系统开发平台上进行，其中，相对稳定的系统平台需要集成一个系统平台版本。 集成测试是将各个子系统组成一个可运行系统的重要阶段。由于一体化软件是系统平台与应用系统几乎同时开发的项目，系统平台内部、应用系统内部，以及平台与应用之间的组装都需在集成测试阶段完成。 生产测试要求集成测试后比较稳定的版本，该版本利用标签进行标示。 4、版本回溯 在测试中，经常出现新修改的程序版本有问题，需要回溯到上一个版本，这是，使用配置管理系统提供的版本管理功能非常方便地回到任意一个程序版本。 七、完善和改进配置管理体系 在两年来的开发管理和版本控制中，有成功也有教训，最初使用配置管理系统时，对其功能和使用方式不熟悉，出现了许多问题，对项目开发产生了一些影响，一度出现了放弃配置管理工具的念头，最终在各方面人员的支持下，使得配置管理系统得以继续在管理中发挥作用。 在系统集成阶段使用配置管理系统进行版本控制，解决了许多问题，促进了开发效率，为项目按期完成提供了有利保证。但是，在管理层次中，开发人员的开发活动没有纳入统一的控制之中，这种方式容易造成修改的版本不是最终版本问题。 为达到上述目的，子系统配置管理员也应该是分支管理员，为此，在集成分支下创建应用子系统的子分支，子分支分别由子系统配置管理员管理并设置用户权限，进行子系统集成，然后再归并到集成分支。 每位开发人员的工作空间都使用与配置管理系统相连的本地工作区，开发活动始终处于受控之中。
八、经验与体会 在版本控制和管理方面的经验主要体现以下几个方面： 1、创建以“版本控制”为中心的大规模软件配置管理体系 对于一体化系统这样前所未有的超大规模、且开发周期仅两年的软件开发项目，如何保证软件开发在有序与受控方式下进行，是项目成功开发要解决的关键问题。 首先，要制定一套体现项目特点的软件配置管理体系，才能使开发处于受控之中。据此，项目组决定引进配置管理系统进行配置管理和版本控制，这也是首次在如此大规模的软件项目中使用配置管理系统。由于是初次使用，基于过去软件开发的经验，结合本项目的特点和软件配置管理的现状，制定了适合本项目的版本控制层次结构（见图1），分支策略和权限控制。 在项目开发过程中，依据每个开发阶段的具体运作实践，对版本控制层次结构和分支策略进行完善与实用化改进。配置管理体系的建立，使开发机构的开发模式逐步迈入工程化开发管理的新时期。 九、结束语 通过两年项目开发实践，许多开发人员对版本控制的概念有了新的认识，从最初的抵触情绪到后来主动要求要使用配置管理系统，基本形成了软件工程化的开发氛围。 |
