工程型软件项目的配置管理实例MSSourceSafe

《工程型软件项目的配置管理实例MSSourceSafe》由会员分享，可在线阅读，更多相关《工程型软件项目的配置管理实例MSSourceSafe（22页珍藏版）》请在装配图网上搜索。

1、工程型软件项目的配置管理实例（一）来源：希赛网 作者：关河 2004/04/22前言软件配置管理作为贯穿软件开发过程始终的一项工作，其重要性不言而喻。51cmm上已有众多关于配置管理介绍、配置管理计划、配置管理工作开展心得一类的文章，这些文章从概念和实施上介绍了配置管理工作的内容，但美 中不足的是仍嫌抽象，那些想要依葫芦画瓢的兄弟姐妹们在试图将这些理论应用到自己项目的配置管理中的时 候，会发现仍然是无从下手（我也曾是这些感觉无从下手的人中的一个）。因此，本文拟从另外一个角度，以本 人最近实际操作的一个项目的配置管理工作谈起，从配置管理工具的选择、配置管理流程制定、配置管理库结构 的确定， 以及

2、作为配置管理工作的推动者如何推动这项工作等方面仔细描述一下本人的做法，希望这几篇文章能给那些水深火热中的兄弟姐妹们一点帮助。这里有两点需要特别说明：1、本文描述的内容是以一个项目的配置管理为主线，对组织级的配置管理和配置管理策略没有进行详细讨论；2、本文用来做示例的项目是一个“工程型”的项目，所谓的“工程型”是和“产品型”对应的，这样的项目需要公司的开发人员和现场的开发人员进行协作开发，一般而言，在公司的开发人员完成大部分的功能，现场的开 发人员根据用户需求，对软件进行修改（这部分的工作量一般会较大，在一个16人年的项目中，这部分的工作可能会占到三分之一以上的工作量）。配置管理工作概述配置管理

3、工作的工作范围，在 51cmm的很多文章中都有描述，具体可以参考河清专栏的基于CMM和CMMI的配置管理和陈越的软件配置管理实施体会。在这里不作详细的描述。本文涉及的项目背景 本文用来示例的项目是某省电信的一个项目，该项目的工作量大约是16人年，项目周期约为 1 年。大部分（ 90%以上）的开发工作在前 8个月内完成， 后期的工作主要由维护人员进行系统维护和调整。在 8个月的开发时间中，前 5 个月由开发人员在公司进行开发，根据用户的需求完成设计，确定系统架构并实现整个框架，部分明确的功 能以及公用模块也在这段时间内完成； 后 3 个月的时间部分开发人员在现场，部分开发人员在公司共同完成后期的

4、开发工作。整个项目采用的开发语言是 C+ Java、ASP,涉及的平台包括Solaris和Windows,采用的开发工具包括 Visual Studio和Solaris上的CC此外，整个项目还使用了一些第三方的平台，如IBM的MQ等。除用户需求之外， 公司还对项目组提出了代码复用方面的要求， 开发人员在开发过程中必须注意代码的可重用性。 配置管理前期准备工作在项目正式启动之后，配置管理工作就可以开始了。配置管理工作开始的第一步就是一份配置管理计划。51cmm上已有不少配置管理计划的模板，大家可以参考。一般而言，需要在配置管理计划中明确的内容包括：1 、 配置管理软硬件资源；2、配置库结构；3、

5、人员、角色以及配置管理规范；4、基线计划；5、配置库备份计划； 在下文中，我们将围绕这些内容进行详细描述。配置管理环境配置管理环境包括软硬件环境。 具体的资源需求应该根据项目实际情况来确定， 一般需要考虑的包括： 网络环境、 配置管理服务器的处理能力、空间需求，配置管理软件的选择等。配置管理环境的确定需要综合考虑各个方面的 因素，包括我们采用的开发工具，开发方式，开发人员对配置管理工具的熟悉程度等，其中，开发人员对配置管 理工具的认可和熟悉程度常常直接决定配置管理能否正常进行，如果选择了需要开发人员花费比较大的精力去熟悉的配置管理软件，我们就必须花费大量时间来进行培训；同时，配置管理软件和开发

6、工具的集成程度也是一个 必须考虑的因素， 根据我们的经验， 选择一个和开发环境集成紧密的配置管理工具至少可以减少20%花费在 CheckIn/Check Out 和配置管理人员保持配置库完整上的工作量。根据我们项目的实际情况，我们有如下一些考虑：根据历史经验，一个类似项目的配置库大小约为3G考虑到备份等操作对空间的需求，至少应该为配置管理库保留10G以上的空间。为了保证配置管理库的安全，除了相应的备份计划之外，还可以采用了RAID 0+ 1的方式为配置数据库提供更好的可用性保证；考虑到在项目的后期有部分开发人员会在现场进行开发，因此在网络条件上需要提供对远程访问方式的支持；配置管理服务器的选择

7、和配置管理软件的选择相关，考虑到目前公司有一台闲置的PC服务器，最好能充分利用这台服务器；配置管理软件必须可以以某种方式支持远程访问，而且由于我们的开发平台涉及Solaris和Windows，配置管理软件要能够支持这两种平台； 考虑到开发工具方面， 配置管理工具要求能和我们选择的开发工具进行很好的集成； 项目组的开发人员缺乏使用配置管理工具的经验，有将约30%勺开发人员使用过 VSS配置管理工具，但仅限于最基础的使用，对 VSS的Label等功能没有概念；结合以上的情况，我们首先考虑配置工具的选择。配置管理工具的选择从开发人员具有的配置管理工具使用经验和配置管理工具使用的难易度方面来说，VSS

8、是最好的选择，在现有的基础上只需要对开发人员进行简单培训；考虑到和开发工具的集成，VSS也是一个不错的选择。不过本项目还要求对远程接入方式的支持，以及对 Solaris平台的支持，VSS肯定是不能满足要求的（VSS通过VPN方式应该是 可以实现对远程访问的支持，但VSS的完全共享方式实在是不敢在Internet上使用）。除VSS外，可以选择的配置管理工具还有CCCHarvest、ClearCase、CVS等，但Harvest和ClearCase使用起来比较复杂，需要一个专门的配置库管理员负责技术支持，还需要对开发人员进行较多的培训，另外，Harvest 和ClearCase价格不菲；CVS在

9、Unix下使用方便，而且是免费的，但其文本方式的操作界面对于习惯在Windows平台上开发的开发人员来说使用非常不习惯（CVS也有windows下的GUI版本，但经过我们的试用，在操作习惯上和我们目前开发人员习惯的方式很不相同，较难被接受）。软硬件环境的选择 确定了配置管理工具后，我们使用公司购置的一台 Compaq PC Server 作为配置管理的硬件环境，该服务器配置 如下：CPU：1CPU， P4 2.0G内存： 512M DDR硬盘空间：30GX 4网卡： HP G bit 网卡一张最终确定的方案是安装该服务器安装 Windows 2000 Server 操作系统，为了保证配置数据的

10、安全性， 我们采用 RAID 0+ 1方式，总的可用空间在 50G左右；另外为了备份的需要，还为服务器配置了一个CDF刻录机。网络环境的选择公司已有现成的100M局域网，通过一个交换机和路由器连接至Internet ，有一个公网的静态IP ;配置管理服务器是内网的一台机器，具有一个内网IP。为了满足远程访问的需要，我们通过在路由器上设置端口映射，将SOS需要使用的端口映射到配置管理服务器上（缺省情况下，SOS使用8888和8890两个端口）。网络拓扑图如下：在公司的开发人员通过局域网使用VSS访问和操作配置库，在现场的开发人员通过Internet 接入对配置库进行访问和操作。配置库维护和备份计

11、划配置库的维护的备份需要专职的配置库管理员来负责。在整个项目中我们采用的配置库维护策略是根据Microsoft 的Best Practice白皮书建议，包括以下要点：1、 保持配置数据库的大小不超过5G; Microsoft建议，配置库的大小在 3-5G比较合适，太大的数据库会极大 影响VSS的效率；减小配置库大小的2、 每周进行VSS数据库的分析（Analysis ），发现问题及时修正；VSS提供了 Analysis和Fix工具，由于不合 理的Delete等操作，VSS数据库有可能会出现一些 Interrupt Data之类的问题，通过定期的每周的分析工作， 可以极大减少数据库岀现问题的风险

12、；3、 每日进行配置库的增量备份，每周进行数据库的完全备份；VSS库的备份可以通过VSS自己的Archive功能或者是操作系统的Backup程序来进行。VSS的Archive功能对VSS中的文件数据进行压缩并保留VSS的所有状态，但只能对VSS库进行完全备份，不能实现增量备份功能。Windows2000 Server提供的Backup实用程序可以对文件进行备份，由于 VSS库就是以文件形势存在的，因此针对VSS的data目录进行备份也可以完全达到备份的目的，使用系统备份工具的好处是可以实现增量备份。我们在实际中使用的系统的备份工具，每周五生成的完全备 份采用刻录光盘的方式保存，每天的增量备份数

13、据存放在文件服务器上进行备份。【小结】在本章中，我们描述了工程型项目配置管理的一些概念，着重介绍了配置管理的环境，包括配置管理工具的选择等。在配置工具选择方面，我们采用VSS+ SOS的组合方案，第二章中，我们将重点介绍VSS和SOSX具的使用，并在介绍配置管理规范中结合配置管理工具讲解具体的操作。工程型软件项目的配置管理实例（二）配置管理双枪将 VSS+ SOS （上）来源：希赛网 作者：关河2004/04/29说起VSS，接触过的人应该不少。尤其是用用 VC和VB做开发的人，绝大多数人应该都接触过和使用过VSS VSS小巧精干，和VS开发工具集成极为紧密，就算不使用专门的配置服务器， 直接

14、在自己的开发用机上安装一个 VSS 也能在代码管理方面方便不少。 SOS在上一章中已经做了介绍，这一章将详细介绍之。VSS概 念也许正因为VSS简单易用，在大多数人眼里，VSS似乎都只是一个玩具，难登大雅之堂，最多能管管自己的代码， 要用团队开发中，那似乎是不可能的。刚接触VSS时，我也是抱着差不多的想法，觉得要用VSS作为一个较大的项目的配置管理工具完全不可能，但随着对VSS研究的深入，加上在工作中也使用了其它一些配置管理工具，如CVS ClearCase、CCC harvest等工具，反过来比较，反而觉得VSS有它独到的地方。关于 VSS和其他配置工具的比较，在google上搜索的话应该能

15、找到一大堆，我这里给岀几个对我来说印象最深刻的VSS的优势：1、 VSS操作使用简单；要在配置管理工具中评选“最平易近人奖”，那一定非VSS莫属。VSS中包含了配置管理需要的全部操作，但应用起来却非常简单，首先是全部操作都可以通过GUI完成，如Check In/Check Out 操作、Get Latest等基本操作；Label、Share、Branch、Merge等高级操作；其次是 VSS和开发环境集成紧密，在 开发环境的 IDE 中就可以方便地完成操作；2、 VSS对硬件配置要求不高；作为一个工作组级别的配置管理工具，在我们的项目中，安装VSS的配置服务器是一台P4 2.2G/512M R

16、AM/30G X 4 Disk的HP PC服务器，这样的条件下 VSS运行已经足够稳定和快速，相比起CC和CCC都运行在Unix平台上需要的维护费VSS；VSS的备份/恢复工作，你说简不简单？：）CC和 CCCharvest的要求，这部分的投资是很小的；如果再考虑到 用，当然是VSS更加划算了；3、 VSS几乎是免费的；只要购买了VS开发工具，就能免费使用4、VSS备份/恢复非常简单；只需要通过拷贝一一覆盖就能完成 5、有良好的可扩展性；通过 VSS的自动化接口（ Automation ），可以自己写程序来完成对 VSS库的访问，也正是基于这点，目前市面上已有一些 VSS的扩展工具出现，我们在

17、本章要讲的就是其中之一Sourcegear的SOS说了这么多优点，当然不是说 VSS就只有优点，和其他的配置管理软件比起来，VSS也有一些不足之处：主要表现在以下几点：1、缺乏对 Unix 的支持（没有 Unix 上的客户端或者服务器，这是微软的一贯作风）；2、不支持远程访问方式（只能通过第三方的扩展工具实现）；3、 支持的配置数据库大小建议不超过5G因此需要良好地规划备份等工作；Project : VSS中类似于文件夹的概念，一个Project可以包含多个File，同时Project也是VSS中权限分配的最小单位，一个 Project 下可以包括其他 Project ；File : VSS中

18、的最小管理单位，VSS中的每个File对象对应操作系统上的一个文件，多个File可以属于一个Project ；Working Folder :和 VSS的Project 对应的本地文件夹。Working Folder 是Get到的Project 和File 的存放目录，同时也是执行 Check In/Check Out 操作时的缓存文件夹；Get （Latest） : Get操作可以获取指定的Project和File的某个版本，常用操作是Get Latest操作，获取Project和 File 的最新版本；Version :对VSS来说，一次Check In操作就为被 Check In的Pro

19、ject或者File增加了一个版本（在文件没有 修改的情况下，Check In操作不生成新的版本）。VSS中的File版本从1开始编号，每次新版本在原有版本上加 1； Project 的版本没有编号；Label ：Label 是配置管理中常用的一个操作， Label 可以作为配置项某个状态的标识；Share: Share可以用于协作开发的模式，通过Share，可以在两个或多个不同的Project之间共享下层的 Project或是 File ，对其中一个位置的 File 进行的修改会反映到其他位置的 File （类似于 Unix 的 ln 的方式）； Branch/Merge ：Branch 和

20、 Merge 可以用于并行开发的过程。SOS（ SourceOffSite ）软件介绍接下来，我们重点介绍 SOS软件，包括软件的安装、配置和使用。SOS软件的安装服务端的安装和设置SOS可以从Sourcegear的网站上下载试用，免费版本可以试用 30天，允许10个用户，目前最新版本是 4.0。不 过为了解决SOS中的中文问题，建议大家从华军软件园中找到中文 SOS进行安装（所谓的中文SOS是国内的高手 修改了 SOS 3.53 程序使其支持中文）。上图是中文SOS安装时的安装界面，选择安装目录等，一路Next，很容易就安装完成了。 安装完成后，系统在“开始”菜单中生成了中文 SOS的相关菜

21、单项目下图是安装完成中文 SOS之后生成的菜单:WindoiM$ U()d8tt帖测H)L豆启动 internet邑 5ymantffcb_PuUishinj-安装完成后，需要对 SOS进行设置。选择中文 SOS菜单的“服务器管理”进入设置界面:System Info 页面显示的是SOS的概要信息;“General Setting”页包含了重要的设置信息，选中“use unsecure port 表示允许使用非加密模式进行数据传输，端口号在后面的编辑框中设置；选中“ use secure port ”表示允许使用加密模式进行数据传输，端口号 在后面的编辑框设置。“ Version 2.0 Co

22、mpatibility用来选择加密模式，一般选择128bit模式即可。在“Logging选项中，选择日志的记录方式；最后的“Idle Connections ，如果选中的话，在指定时间内没有数据传输的话， 连接就会自动断开Server MdniiQet 3.3Serial Number ”页面用来管理 SOS的license。通过Add按钮可以增加新的 Serial NumberSOS中可以添加多个 Serial Number 。“Databases ”页面用来添加SOS管理的VSS数据库。点击Add按钮可以添加数据库，添加对话框的上一个框填 入VSS库的ini文件所在路径，下一个是数据库的别

23、名，可以任意设置。SOS可以同时管理多个数据库。“Users”页面输入SOS中有效的用户和使用规则，注意，这里的用户和VSS的用户没有关系，VSS用户和SOS用户的关联在下面的“ User Keys ”页面中设置。要说明的是规则的描述：“Users ”中的一行对应一个规则，每行的开头是规则的编号，第二个字段是用户名，第三个字段是允许访问的网络段，第四个字段（取值为0、1、2）是控制访问允许以及访问是否使用加密方式的描述（0表示部允许访问；1表示要求加密访问；2表示允许使用加密或者不加密方式访问）。这里要说明的是“用户”的概念 应。VSS中的用户对SOS没有自己的用户概念，SOS中的用户通过用户

24、名称和工程型软件项目的配置管理实例（二）配置管理双枪将 VSS+ SOS （下）来源：希赛网 作者：关河2004/04/29“User Keys ”页面用来生成客户端访问控制的Key文件：Inlo1 G4Wl*SMhDl 1曲H曲工Umhu*亞即W百 FiRtcn | Chsbug1PinSbjppgilUs-rr1岸申删DeMa Heml QMMev |AM U0Humh 1力 R厂EvoYew M cknlw1输入完相应信息后，点击“ OK确认生成用户Key文件。生成的用户 Key文件保存在SOS安装目录下，文件名为用户名.iky ，注意保留此文件，SOS客户端在启动时需要首先导入一个ke

25、y文件。“Web Project ”页面用于设置 Web Project的发布路径：| 竽 H0mi.niinsrte LI jsic 5jv-i Managit X5.5E3|:SyiAw Inf| G嘴八静7 SftUnfs |HwbtTs | Vs*? sVi*r Etffl軋恵 |Tilt Tjti Fiih. Svp|$rlSbur亡boj.cl Hhii丄 叹 mcMy|贞蛆 |Miu. |鹉走砂gg 在第一个编辑框中填入该工程在VSS中的路径，例如“ $/WebProject1/test，在下面的编辑框中输入发布的路径，例如“ d:temp 。发布路径也可以是在其他机器上的网络路

26、径。“Debug”页面是两个调试级别的选项： 踊足 鬼甫 I二:口垃这两个选项的具体含义在SOS的Manual中也没有明确提到，我们在实际运用中也没有发现该选项的具体作用,建议不选取。“ Excluded File Types页面设置不允许添加到 VSS库中的文件类型：添加的条目是文件后缀，具有在列表中的后缀的文件都不能被添加到VSS库中“Pin Support 页面用于设置是否允许PIN操作：如果允许“ PIN”操作，还需要指定 ss.exe文件所在的目录。设置完成后，需要重新启动 SOS服务端，具体方法是在“服务”中启动相应服务：启动服务完成后，服务端的安 装设置就已经完成了，接下来我们介

27、绍SOS客户端的安装和使用。SOS客户端的安装和使用SOS的客户端分为 Windows版本、Solaris版本和Linux版本。Windows版本的安装非常简单， 直接执行安装程序 就可以顺利安装。Solaris版本的SOS客户端以tar形式发布，首先在 Solaris上安装GTK和GLIB，然后展开安 装程序到任意目录即可。对Linux版本的SOS客户端，也需要首先安装GTK和 GLIB，然后展开相应tar包到任意 目录即可。Solaris、Linux和Windows版本的SOS客户端运行界面都非常类似，下面以Windows版本为例说明其使用。第一次运行SOS客户端时，系统会弹出一个对话框要

28、求输入服务器和端口号。这时用“Cancel”按钮取消，选择菜单项的“ Tools ”“Import Encryption Key ”，导入服务端生成的Key文件：导入完成后，选择菜单项的“ File ” 一一 “Connect to Server”，输入服务器IP地址和端口，如果连接成功, 系统会给岀可以连接的数据库列表，可以从列表中选择合适的数据库进行连接访问。连接成功后，显示的主界面和 VSS的基本一致，SOS的操作方式和VSS的也一样，具体可以参见 VSS的文档 下图是SOS的主界面：w t-192-1 津 I sail 2 (TIME) - *Jdi*i g irw1也IFrit bu

29、fM MITf.1 + .|x| M 於咁|工护丹| _._电I 釧 Qll Jl|当然，SOS在操作上也有一些和 VSS不同的地方，下面列出这些不同点：1、缺省设置下，SOS每次登录不会主动刷新工程树和文件列表，需要用工具条上的刷新按钮进行刷新;2、SOS的“ Search ”功能较 VSS弱，只能查找 Check Out的文件；3、 SOS的Option设置项目很多，大部分都是SOS增加的为适应远程连接的设置项：Doubledi cL on i.Flit TgMCwm nJid * J d 官性GtMf al|Va evHIMTP PrKOptionrsR厂厂y. CDDprtE en f

30、or dtla IfiliAct prcijscU xagvECC TreviMikfe SawctOfSi t ycnar dtftuli【小结】本章介绍了 VSS SOS的使用，重点是SOS的安装和使用方法。SOS在使用上其实还有很多小技巧，在此 不能一一列举，在sourcegear的网站上都能找到相关的资料。在下一章中，我们将结合配置管理工具介绍配置 管理规范的内容。工程型软件项目的配置管理实例（三）配置管理规范来源：希赛网 作者：关河2004/05/17配置管理规范对于一个一般的项目来说，配置管理规范的内容至少需要包括以下的内容：1、配置项及其命名规则；2、配置库文件目录结构；3、角色

31、和权限定义；4、配置项变更流程；5、配置项发布；6、基线定义和基线变更。配置项及其命名规则对我们的项目来说，配置项需要包括以下的内容：1、项目管理过程文档；a）项目任务书；b）项目计划；c）项目周报；d）个人日报和周报；e）项目会议纪要；f）培训记录和培训文档；2、QA过程文档；a）QA不符合报告；b）QA周报；c）评审记录；3、工作产品a）需求文档；b）设计文档；c）代码；d）测试文档；e）软件说明书和手册；4、项目中使用的第三方产品上文中用红色部分标识的是容易遗漏的配置项，尤其是第4个（项目中使用的第三方产品），实际上，一个工程型的项目会大量使用第三方的软件（例如，我们的产品中就使用了 I

32、BM的MQSeries、Oracle、一些第三方的开发控件），对这些产品的管理至少可以解决三个方面的问题：1、版本配合的问题：大部分的第三方软件在升级之后，并不能实现二进制层面上的兼容，需要对原有的代码重新编译；甚至有的第三方软件在升级之后，API层面上的兼容性都做不到；因此，在工程实施的过程中，版本的配合问题是一个需要关注的问题；2、发布的完整性问题：一般来说，比较大型的第三方软件在发布过程中都不会有遗漏，但对一些小的第三方软 件来说，比如我们使用的许多 perl的CPan模块，如果在开发过程中没有有意识的进行管理的话，很容易就会发 生遗漏；3、在某些特殊条件下由于第三方软件的变化引起的基线

33、变更：这种情况极少会发生，但在我们以前的项目中， 确实还遇见过。一般是因为原来选型时使用的第三方软件不能满足要求，只能通过更换新的第三方软件，这就补 课避免地需要变更基线（例如需求文档、设计文档等）；将第三方软件纳入配置管理的范畴可以更方便地管理基 线的变更。关于第三方软件产品配置项的管理还有一点需要说明：由于第三方软件有可能会比较大，而且相对我们的项目来 说，是很少会发生变更的（一般在一个项目过程中，不会采用不同的配置项的命名可以便于查找相关配置项。配 置项的命名包括两个方面的内容：1、配置项标识：在我们的项目中，一般使用“项目名配置类别配置项特殊标识”来命名。下表列岀了我们在项目中使用的配

34、置类别命名：配置类别命名配置类别命名项目任务书PT项目计划PP项目周报PR个人日报和周报PER项目会议纪要PM培训记录和培训文档TRQA不符合报告QAPQA周报QAR评审记录RR需求文档REQ设计文档DD代码CODE测试文档TD软件说明书和手册MAN项目中使用的第三方产品PART3配置项命名中的“配置项特殊标识”根据配置类别的不同而不同。比如，对“设计文档”，如果细分的话，可以 分为“概要设计”和“详细设计”；对“代码”，可以按照模块来命名配置项。2、配置项版本命名：配置项版本命名是针对配置项的版本进行命名，在我们的项目中，配置项版本通过对 Project的Label操作来实现，配置项版本的命

35、名需要能清楚标识配置项的状态。一般说来，配置库至少包括个人工作区、受控库、发布区三个部分，在我们的项目中，所有的配置项都保存在一个VSS库中，对这三个部分的划分是通过逻辑划分方式进行的，具体来说，就是通过配置项版本命名来划分的。因此，我们配置项的版本命名规定如下：a）基线版本：按照基线的状态，我们这个项目中的基线有两个方面：一是作为里程碑的基线；另一个是模块的 阶段性成果基线（对工作产品而言），由模块的负责人确定。里程碑基线一一对我们的项目来说，采用的是迭代的开发过程，以一个迭代过程为例，分为需求、概要设计、详 细设计、代码实现、单元测试、集成测试、系统测试七个阶段，每个阶段都需要产生里程碑。

36、对每个里程碑都有 明确的标识标明当前状态。阶段性成果基线一一阶段性成果主要体现在代码过程中，比如代码进行到一个阶段，开发组长认为代码的这个状 态可以保留，就可以确定为一个代码基线。这种基线一般不需要通过评审等正式手段来确定，但也必须有相应的 验证手段；比如在我们的项目中，在代码阶段，确定代码基线的责任人是开发组长，但开发组长必须保证代码基 线符合一定的条件。b）其他版本：除基线版本外，有时候还需要在开发和维护过程中确定其他版本。例如，产品在测试过程中不断 的问题修复过程中，可能会有多种反复，此时需要将每次修改的内容作为一个版本。关于版本，还有另一个需要注意的问题。一般来说，按照模块来划分，每个

37、模块有自己的版本演进比较合理。首 先，一个模块一般是由一个或两个开发人员完成的；其次，一个模块的功能会比较单一且独立，在版本的演化过 程中便于控制，也不会和其他模块产生过于复杂的关系。而产品的版本则需要由各个模块的不同版本组成，这个 纵横的关系需要很好地管理，我们的做法是在VSS库上用Label来标识，同时维护一张描述产品版本和模块版本关系的矩阵图便于追踪。配置库目录结构在确定了配置项之后， 就可以确定配置库的目录结构了。配置库的目录结构直接关系到配置管理的工作量和使用 的方便性，所以需要根据自己的需要确定一个合理的结构。在确定配置管理库目录结构的时候，我们曾经考虑过两种产品目录结构的方式：一

38、种是按照模块划分，在模块下 再划分诸如设计文档、代码等目录；另一种方式是按照产品类型划分，例如首先是文档、代码，然后在其下按照 模块划分。这两种方式都有自己的优点，最终我们还是选择了前一种划分方式，一方面是考虑便于进行权限的分 配，另一方面是考虑到便于将同一模块的所有内容组织起来进行版本的管理。下表是我们在实际中采用的配置库结构（部分）第一级第二级第三级第四级说明M管理类文档PM项目管理0 Init初始阶段PCPTRPN1 Plan计划阶段QA0 PPQAP质量保证计划P项目产品0 Req需求阶段0 CRS客户需求1 SRS需求分析文档2 RTM需求跟踪矩阵1 Des设计阶段0 HLD概要设计

39、1 DBD数据库设计2 Imp实现/编码阶段0 Module1模块10 COD代码1 DDS详细设计2 HLD概要设计3 UNT单元测试3 Test0 Int集成测试1 Syt系统测试4 Man手册5 Others其他从这里的配置库结构中可以看到，我们在最上层将配置项分为管理类和产品类：管理类中的项目管理部分基本是按照初始一计划一执行一收尾四个阶段来划分。在项目产品类别中，我们按照需求一设计一实现一测试四个阶段 划分目录，在实现阶段，为每个模块划分了代码、详细设计、概要设计和单元测试四个目录，需要说明的是，在 第三层中有一个HLD的目录，在模块下同样有一个 HLD的目录，在我们的实际工作中，第

40、三层的HLD目录用来存放系统级别的概要设计文档，而模块下的HLD目录用来存放模块级别的概要设计文档。当然，这里的配置库结构仅仅起到了示范作用，在实际使用中，可以根据自己的需要修改。例如，在Module的级别上可以增加一个 SubSystem的层，便于在产品集成时更加方便。角色定义及权限分配角色是配置管理流程的执行者和参与者，定义明确的角色有利于实现明确的授权和明晰的流程，虽然在实际中可能多个角色由一个人担任，但还是应该保留角色的定义。下面是该项目中我们的角色定义：配置管理员整个配置管理库由配置管理员管理。配置管理员负责分配和修改其他成员的权限，要维护所有目录和配置项。开发经理开发经理在本项目中

41、负责主导完成需求分析和系统总体设计，对项目的总体进度负责。开发经理拥有对管理类文档的读取权限，可以对项目类文档进行读写操作；开发组长开发组长对本小组的工作负有组织和管理任务，同时开发组长也需要承担一定的开发任务。开发组长对管理类文档有读取权限，对本组负责的模块有读取权限，对自己负责的模块有读写的权限；开发工程师开发工程师完成具体的开发任务，对自己负责的模块目录有读写权限，对管理类文档有读取权限；测试组长测试组长负责组织测试，给岀测试计划和测试方案，并核定测试报告。测试组长对所有目录都有读取权限，对测 试目录有读写权限；测试工程师测试工程师负责完成测试工作，包括测试用例开发和测试执行，测试报告编

42、写。测试工程师对自己负责的模块有读取权限，对测试用例目录有读写权限。QA工程师QA工程师拥有对所有目录的读取权限，拥有对QA类文档目录的读写权限。说明除配置管理员外，其他所有成员都没有Destroy目录和文件的权限，这是为了防止误删除操作带来不可挽回的损失。如果需要对目录进行Destroy操作，必须由配置管理员进行。【小结】在本章中，我们介绍了配置管理规范的配置项及其命名、配置库的目录结构以及配置管理的角色权限分配。在下一章中，我们将介绍完配置管理规范的其他内容并给岀配置管理实施过程中的一些心得体会。工程型软件项目的配置管理实例（四）配置项的变更与发布来源：希赛网 作者：关河2004/05/2

43、7配置项变更流程我们所说的配置项变更流程主要是针对配置项发生变化的控制，在我们的项目中分为两个部分，首先是对配置项新建、检入（Checkin）和检出（Checkout）的规定；其次是对入库的文件类型和大小的规定：新建、检入、检岀及破坏1、 新建：即Add,除特殊情况外，一般不规定由谁来新建（只要有权限即可），但尽量指定每个project只有 一人负责新建。2、检入：即check in，检入频率规定如下：i. 在代码编写前，至少每周一次ii. 代码编写阶段，至少每天一次iii. 测试阶段以后，根据代码、文档的变动，只要当天有变动就要检入一次。iv. 为配合检查、备份工作，需在检查备份周期前全部c

44、heck in （不保持check out）并退出登录。详见“检查及备份”部分3、检出：即check out。原则上只对要修改的文档方可检出。4、破坏（Destroy ）:一般情况不可以破坏文件、目录。5、如果是误操作，则可在一天内提交管理员处6、如果超过一天，则需要由项目经理同意，且管理员破坏前要备份。7、各阶段环境职责环境阶段负责人职责公司内部编码前开发人员每周及需要评审前check in工作产品（包括版本发布说明）到VSS上开发组长每周SCM人 员每周统计编码开发人员每天check in 工作产品（包括版本发布说明）到vss上开发组长每周检查经理及组长抽查及走读SCM人 员每周统计，检查

45、代码风格测试开发人员每天check in工作产品到vss上（如当天没有修改可以不进行 check in ）以LABEL形式提交一个新版本给测试，附带版本发布说明测试人员对测试完成后的程序打 LABEL发布后开发人员将新版本check in 到vss,打测试LABEL,向测试人员提交申请测试人员对测试完成后的程序打 LABELSCM人 员对变更做好控制和记录，并发布现场开发负责人将发布后的产版本更新至现场，或指定人员进行公司外部编码现场开发负责人在无法通过sos连到公司vss的情况下，需要在现场建立 配置库（文件方式或 VSS等），做到基本的版本控制和备 份。每周至少通过SOS提交一次至公司的

46、VSS库中。现场开发人员每天check in工作产品到现场配置库（包括版本发布说 明）。SCM人 员做好督促和监督工作，每周将现场开发负责人提交的现场 版本更新到公司配置库（vss ）。测试现场开发人员每天check in工作产品到现场配置库（如当天没有修改可 以不进行check in ）。如已经回公司则每天 check in工作产品到公司配置库vss（如当天没有修改可以不进行check in ）。每周通过SOS提交一个新版本给测试，打测试LABEL,附带版本发布说明（如没有更新可不提交）对测试完成后的程序打 LABELSCM人 员做好督促和监督工作发布后现场调试现场维护现场开发负责人在无法通

47、过sos连到公司vss的情况下，需要在现场建立 配置库（文件方式或 VSS等），做到基本的版本控制和备 份。每周至少通过 SOS提交一次至公司的 VSS库中。通过 LABEL提交测试版本现场开发人员对修改后的版本通过 SOS check in 新版本到vss,打测试LABEL，向测试人员提交申请（由修改至提交测试人员不应超过三天）测试人员对测试完成后的程序打 LABELSCM人 员对变更做好控制和记录，并发布做好督促和监督现场提交更新版本到vss。关于VSS库内存放文件类型及大小的规定1、文件名及目录规定：以英文名字命名2、文件大小规定：最大不超过 20M3、允许类型：4、表2.1中提至的文档

48、类5、代码及脚本类及为配合编译需要的类库等6、以下类型不允许存放在 VSS库中：7、备份数据8、安装程序、打包程序（ziprar ）9、超过20M以上的非代码类及开发文档类文件10、对于特殊情况或不确定情况，需向配置管理人员咨询后再加入11、 对于不允许存放类型的配置类文件，可与配置管理员联络，随件附说明清单，以文件型式保存于服务 配置项发布配置项发布是指配置项进行到一定的阶段（例如，里程碑阶段），需要对外发布时的规则。在我们的项目中，配 置项发布是通过标签，即 LABEL来实现的。阶段触发事件操作人标签类型打标签的级别单元测试单元测试完成，可以提交集成测试开发人员FOR_TEST模块级集成测

49、试集成测试完成，不通过（如通过进入系统测 试阶段）测试人员TESTED模块级BUG修改完成，可以提交测试开发人员FOR_TEST模块级集成测试通过，可以提交系统测试测试负责人TESTED模块级系统测试系统测试完成后，不通过，（如通过进入系 统测试阶段）测试负责人TESTED项目级BUG修改完成，可以提交测试开发人员FOR_TEST项目级系统测试通过测试负责人TESTED项目级验收测试验收前的版本，可发布到现场安装配置管理员LOAD项目级验收后的版本，可发布的正式版本配置管理员LOAD项目级现场维护修改BUG后提交测试维护工程师FOR_TEST模块级/项目级/文件级测试通过与否测试人员TESTE

50、D模块级/项目级/文件级基线确立与变更基线的确定在上一部分中已经说到过，我们的项目基线分为两类，一类是作为里程碑和其他工作依赖的基线（例 如需求文档、设计文档等），另一类是开发过程中有必要保留的一种状态（例如代码过程中某个模块的一个有保 留价值的snapshot ）。对这两种不同的基线，其影响的范围不同，确立和变更方式也不一样。我们项目的基线变更控制委员会由客户代表、产品经理、项目经理以及技术经理组成，对发布的里程碑类基线的 变更必须由变更控制委员会确认并由QA进行变更记录，所有被变更影响的配置项都需要重新同步后再次发布;而对于仅仅作为工作状态保留的基线，一般只需要建立基线的小组确认更改并在Q

51、A进行记录即可。检查与备份1、 检查：根据VSS白皮书建议，要定期检查数据的正确性。故VSS库管理员应每周检查一次，流程如下：a) 开发人员于每周五下午 5:30 前 check in ( ( 不保持 check out) )并退出登录b) VSS库管理人员用analyze工具检查VSS数据库，操作如下：在 dos 命令行中输入： analyze - f - d - c - v4 c:vssdata其中“ c:vssdata ”为 vss 库的数据目录2、 备份：a) 每天增量备份，通过 windowsNT 以上自带的备份工具进行增量备份，备份以硬盘存放即可。b) 每周全备份：每周检查完毕之后

52、，对VSS数据库进行全备份，建议以光盘介质备份。配置管理实施后记 应该说，这次我们对项目的配置管理实施是非常成功的，在整个开发过程中，基本没有出现因为配置管理的问题 导致的对开发进度的延误。当然，在开发过程中也发生了由于需求变化导致基线变更引起开发进度的延迟，不过 这不应该算作是配置管理的失误，因为作为配置管理来说，只能尽量保证基线变更不会导致项目失控。 总结我们这次的配置管理实施工作， 除了这几篇文章中讲到的需要注意的问题外，我觉得有一些应该算做是决定 实施成败的关键因素：1、一个好的执行人员是成功的关键； 一个好的执行人员的重要性怎么强调都不过分。所谓的一个好的执行人员应该具备这样的素质：

53、a) 对配置管理工作有较为深刻的理解；b) 对使用的配置管理工具运用熟练；c) 具有好的沟通能力，能和开发组长、开发人员以及其他干系人沟通；d) 有好的执行力，对流程的执行能起到监督和推动作用；e) 耐心细致，很多时候，细节决定了成败；2、好的工具能起到事半功倍的效果；选择一个合适的配置管理工具绝对是必要的， 我们在前面用了一章多的篇幅介绍我们使用的配置管理工具及其方 案，事实证明，我们选择的配置管理工具对我们项目管理实施的效果是决定性的。3、在配置管理实施的初期，及时的指导起的作用是巨大的，甚至可以说是成功的主要因素； 对不熟悉配置管理的开发工程师来说， 配置管理工作容易在一开始就让他们产生

54、厌烦情绪， 一点点使用上的不方 便就会导致开发人员对配置管理的怨言， 这个时候， 及时的指导就显得非常重要了， 我们在配置管理实施过程中， 准备了VSS操作手册、SOS简明操作手册、配置管理操作指导书等手册，进行了三次的培训，并在 实施过程中随时解决开发人员在使用配置管理工具中的问题。而且，在实施初期，我们以奖励为主，在一个月的 时间内没有将配置管理工作作为考核内容。4、每周的配置状态检查非常重要；在配置管理基本走上正规后， 每周的配置状态检查是我们对配置管理执行效果的检查， 一旦发现问题， 会作为 QA 问题报告发出并要求限期改正。如果没有这个检查制度，配置管理工作很难持续受控。后记工程型软件项目配置管理实例 这几篇文章是我们在项目的配置管理实施过程中的一些体会，和其他配置管理 文章不同的是，这里我们给出的都是马上就可以应用的实践步骤。当然，每个公司的环境各有不同，同样的实践 不可能在每个地方都能产生一样的效果，只是希望这一系列文章能给大家一些启发。 时间仓促，文章中有些地方可能还有未能表达清楚的地方，欢迎大家和我探讨。