工程软件项目的配置管理实例.docx
《工程软件项目的配置管理实例.docx》由会员分享，可在线阅读，更多相关《工程软件项目的配置管理实例.docx（31页珍藏版）》请在冰点文库上搜索。
工程软件项目的配置管理实例
工程型软件项目的配置管理实例
（一）
前言
1、本文描述的内容是以一个项目的配置管理为主线，对组织级的配置管理和配置管理策略没有进行详细讨论；
2、本文用来做示例的项目是一个“工程型”的项目，所谓的“工程型”是和“产品型”对应的，这样的项目需要公司的开发人员和现场的开发人员进行协作开发，一般而言，在公司的开发人员完成大部分的功能，现场的开发人员根据用户需求，对软件进行修改。
配置管理工作概述
配置管理工作的工作范围，在51cmm的很多文章中都有描述，具体可以参考河清专栏的《基于CMM和CMMI的配置管理》和陈越的《软件配置管理实施体会》。
在这里不作详细的描述。
本文涉及的项目背景
本文用来示例的项目是某省电信的一个项目，该项目的工作量大约是16人年，项目周期约为1年。
大部分（90%以上）的开发工作在前8个月内完成，后期的工作主要由维护人员进行系统维护和调整。
在8个月的开发时间中，前5个月由开发人员在公司进行开发，根据用户的需求完成设计，确定系统架构并实现整个框架，部分明确的功能以及公用模块也在这段时间内完成；后3个月的时间部分开发人员在现场，部分开发人员在公司共同完成后期的开发工作。
整个项目采用的开发语言是C++、Java、ASP，涉及的平台包括Solaris和Windows，采用的开发工具包括VisualStudio和Solaris上的CC。
此外，整个项目还使用了一些第三方的平台，如IBM的MQ等。
除用户需求之外，公司还对项目组提出了代码复用方面的要求，开发人员在开发过程中必须注意代码的可重用性。
配置管理前期准备工作
在项目正式启动之后，配置管理工作就可以开始了。
配置管理工作开始的第一步就是一份配置管理计划。
51cmm上已有不少配置管理计划的模板，大家可以参考。
一般而言，需要在配置管理计划中明确的内容包括：
1、配置管理软硬件资源；
2、配置库结构；
3、人员、角色以及配置管理规范；
4、基线计划；
5、配置库备份计划；
在下文中，我们将围绕这些内容进行详细描述。
配置管理环境
配置管理环境包括软硬件环境。
具体的资源需求应该根据项目实际情况来确定，一般需要考虑的包括：
网络环境、配置管理服务器的处理能力、空间需求，配置管理软件的选择等。
配置管理环境的确定需要综合考虑各个方面的因素，包括我们采用的开发工具，开发方式，开发人员对配置管理工具的熟悉程度等，其中，开发人员对配置管理工具的认可和熟悉程度常常直接决定配置管理能否正常进行，如果选择了需要开发人员花费比较大的精力去熟悉的配置管理软件，我们就必须花费大量时间来进行培训；同时，配置管理软件和开发工具的集成程度也是一个必须考虑的因素，根据我们的经验，选择一个和开发环境集成紧密的配置管理工具至少可以减少20%花费在CheckIn/CheckOut和配置管理人员保持配置库完整上的工作量。
根据我们项目的实际情况，我们有如下一些考虑：
根据历史经验，一个类似项目的配置库大小约为3G，考虑到备份等操作对空间的需求，至少应该为配置管理库保留10G以上的空间。
为了保证配置管理库的安全，除了相应的备份计划之外，还可以采用了RAID0＋1的方式为配置数据库提供更好的可用性保证；
考虑到在项目的后期有部分开发人员会在现场进行开发，因此在网络条件上需要提供对远程访问方式的支持；
配置管理服务器的选择和配置管理软件的选择相关，考虑到目前公司有一台闲置的PC服务器，最好能充分利用这台服务器；
配置管理软件必须可以以某种方式支持远程访问，而且由于我们的开发平台涉及Solaris和Windows，配置管理软件要能够支持这两种平台；考虑到开发工具方面，配置管理工具要求能和我们选择的开发工具进行很好的集成；
项目组的开发人员缺乏使用配置管理工具的经验，有将约30%的开发人员使用过VSS配置管理工具，但仅限于最基础的使用，对VSS的Label等功能没有概念；结合以上的情况，我们首先考虑配置工具的选择。
配置管理工具的选择
从开发人员具有的配置管理工具使用经验和配置管理工具使用的难易度方面来说，VSS是最好的选择，在现有的基础上只需要对开发人员进行简单培训；考虑到和开发工具的集成，VSS也是一个不错的选择。
不过本项目还要求对远程接入方式的支持，以及对Solaris平台的支持，VSS肯定是不能满足要求的（VSS通过VPN方式应该是可以实现对远程访问的支持，但VSS的完全共享方式实在是不敢在Internet上使用）。
除VSS外，可以选择的配置管理工具还有CCCHarvest、ClearCase、CVS等，但Harvest和ClearCase使用起来比较复杂，需要一个专门的配置库管理员负责技术支持，还需要对开发人员进行较多的培训，另外，Harvest和ClearCase价格不菲；CVS在Unix下使用方便，而且是免费的，但其文本方式的操作界面对于习惯在Windows平台上开发的开发人员来说使用非常不习惯（CVS也有windows下的GUI版本，但经过我们的试用，在操作习惯上和我们目前开发人员习惯的方式很不相同，较难被接受）。
经过在MSDN和Internet上查找，终于找到了一个VSS的增强软件SOS（SourceOffsite），它基于VSS的数据库，可以支持通过TCP/IP方式访问和操作VSS库，在Windows、Slolaris和Linux上都提供了客户端，并且通过传输数据的压缩和加密方式，使得文件操作的速度大大加快并增强了系统的安全性。
SOS可以在SourceGear的网站上找到详细介绍和试用的下载（
软硬件环境的选择
确定了配置管理工具后，我们使用公司购置的一台CompaqPCServer作为配置管理的硬件环境，该服务器配置如下：
CPU：
1CPU，P42.0G
内存：
512MDDR
硬盘空间：
30G×4
网卡：
HPGbit网卡一张
最终确定的方案是安装该服务器安装Windows2000Server操作系统，为了保证配置数据的安全性，我们采用RAID0＋1方式，总的可用空间在50G左右；另外为了备份的需要，还为服务器配置了一个CDR刻录机。
网络环境的选择
公司已有现成的100M局域网，通过一个交换机和路由器连接至Internet，有一个公网的静态IP；配置管理服务器是内网的一台机器，具有一个内网IP。
为了满足远程访问的需要，我们通过在路由器上设置端口映射，将SOS需要使用的端口映射到配置管理服务器上（缺省情况下，SOS使用8888和8890两个端口）。
网络拓扑图如下：
在公司的开发人员通过局域网使用VSS访问和操作配置库，在现场的开发人员通过Internet接入对配置库进行访问和操作。
配置库维护和备份计划
配置库的维护的备份需要专职的配置库管理员来负责。
在整个项目中我们采用的配置库维护策略是根据Microsoft的BestPractice白皮书建议，包括以下要点：
1、保持配置数据库的大小不超过5G；Microsoft建议，配置库的大小在3－5G比较合适，太大的数据库会极大影响VSS的效率；减小配置库大小的
2、每周进行VSS数据库的分析（Analysis），发现问题及时修正；VSS提供了Analysis和Fix工具，由于不合理的Delete等操作，VSS数据库有可能会出现一些InterruptData之类的问题，通过定期的每周的分析工作，可以极大减少数据库出现问题的风险；
3、每日进行配置库的增量备份，每周进行数据库的完全备份；VSS库的备份可以通过VSS自己的Archive功能或者是操作系统的Backup程序来进行。
VSS的Archive功能对VSS中的文件数据进行压缩并保留VSS的所有状态，但只能对VSS库进行完全备份，不能实现增量备份功能。
Windows2000Server提供的Backup实用程序可以对文件进行备份，由于VSS库就是以文件形势存在的，因此针对VSS的data目录进行备份也可以完全达到备份的目的，使用系统备份工具的好处是可以实现增量备份。
我们在实际中使用的系统的备份工具，每周五生成的完全备份采用刻录光盘的方式保存，每天的增量备份数据存放在文件服务器上进行备份。
【小结】在本章中，我们描述了工程型项目配置管理的一些概念，着重介绍了配置管理的环境，包括配置管理工具的选择等。
在配置工具选择方面，我们采用VSS＋SOS的组合方案，第二章中，我们将重点介绍VSS和SOS工具的使用，并在介绍配置管理规范中结合配置管理工具讲解具体的操作。
工程型软件项目的配置管理实例
（二）
——配置管理双枪将VSS＋SOS（上）
说起VSS，接触过的人应该不少。
尤其是用用VC和VB做开发的人，绝大多数人应该都接触过和使用过VSS。
VSS小巧精干，和VS开发工具集成极为紧密，就算不使用专门的配置服务器，直接在自己的开发用机上安装一个VSS，也能在代码管理方面方便不少。
SOS在上一章中已经做了介绍，这一章将详细介绍之。
VSS概念
1、VSS操作使用简单；VSS中包含了配置管理需要的全部操作，但应用起来却非常简单，首先是全部操作都可以通过GUI完成，如CheckIn/CheckOut操作、GetLatest等基本操作；Label、Share、Branch、Merge等高级操作；其次是VSS和开发环境集成紧密，在开发环境的IDE中就可以方便地完成操作；
2、VSS对硬件配置要求不高；作为一个工作组级别的配置管理工具，在我们的项目中，安装VSS的配置服务器是一台P42.2G/512MRAM/30G×4Disk的HPPC服务器，这样的条件下VSS运行已经足够稳定和快速，相比起CC和CCCharvest的要求，这部分的投资是很小的；如果再考虑到CC和CCC都运行在Unix平台上需要的维护费用，当然是VSS更加划算了；
3、VSS几乎是免费的；只要购买了VS开发工具，就能免费使用VSS；
4、VSS备份/恢复非常简单；只需要通过拷贝——覆盖就能完成VSS的备份/恢复工作。
5、有良好的可扩展性；通过VSS的自动化接口（Automation），可以自己写程序来完成对VSS库的访问，也正是基于这点，目前市面上已有一些VSS的扩展工具出现，我们在本章要讲的就是其中之一——Sourcegear的SOS。
说了这么多优点，当然不是说VSS就只有优点，和其他的配置管理软件比起来，VSS也有一些不足之处：
主要表现在以下几点：
1、缺乏对Unix的支持（没有Unix上的客户端或者服务器，这是微软的一贯作风）；
2、不支持远程访问方式（只能通过第三方的扩展工具实现）；
3、支持的配置数据库大小建议不超过5G，因此需要良好地规划备份等工作；
关于VSS的操作和应用，建议在网上找找VSS的教程，写得比较详细的有不少，都可以参考。
在SourceSafe6.0实用指南》，在这里我只是非常概括地介绍一些VSS的基本概念：
Project：
VSS中类似于文件夹的概念，一个Project可以包含多个File，同时Project也是VSS中权限分配的最小单位，一个Project下可以包括其他Project；
File：
VSS中的最小管理单位，VSS中的每个File对象对应操作系统上的一个文件，多个File可以属于一个Project；
WorkingFolder：
和VSS的Project对应的本地文件夹。
WorkingFolder是Get到的Project和File的存放目录，同时也是执行CheckIn/CheckOut操作时的缓存文件夹；
Get（Latest）：
Get操作可以获取指定的Project和File的某个版本，常用操作是GetLatest操作，获取Project和File的最新版本；
Version：
对VSS来说，一次CheckIn操作就为被CheckIn的Project或者File增加了一个版本（在文件没有修改的情况下，CheckIn操作不生成新的版本）。
VSS中的File版本从1开始编号，每次新版本在原有版本上加1；Project的版本没有编号；
Label：
Label是配置管理中常用的一个操作，Label可以作为配置项某个状态的标识；
Share：
Share可以用于协作开发的模式，通过Share，可以在两个或多个不同的Project之间共享下层的Project或是File，对其中一个位置的File进行的修改会反映到其他位置的File（类似于Unix的ln的方式）；
Branch/Merge：
Branch和Merge可以用于并行开发的过程。
SOS（SourceOffSite）软件介绍
接下来，我们重点介绍SOS软件，包括软件的安装、配置和使用。
SOS软件的安装
SOS软件分为服务端和客户端两个部分，客户端运行在配置管理服务器上，客户端运行在需要访问配置库的客户机上。
以下以SOS3.5.3标准版的SOS为例，说明该软件的安装、配置和使用。
服务端的安装和设置
SOS可以从Sourcegear的网站上下载试用，免费版本可以试用30天，允许10个用户，目前最新版本是4.0。
不过为了解决SOS中的中文问题，建议大家从华军软件园中找到中文SOS进行安装（所谓的中文SOS是国内的高手修改了SOS3.53程序使其支持中文）。
上图是中文SOS安装时的安装界面，选择安装目录等，一路Next，很容易就安装完成了。
安装完成后，系统在“开始”菜单中生成了中文SOS的相关菜单项目。
下图是安装完成中文SOS之后生成的菜单：
安装完成后，需要对SOS进行设置。
选择中文SOS菜单的“服务器管理”进入设置界面：
“SystemInfo”页面显示的是SOS的概要信息；
“GeneralSetting”页包含了重要的设置信息，选中“useunsecureport”表示允许使用非加密模式进行数据传输，端口号在后面的编辑框中设置；选中“usesecureport”表示允许使用加密模式进行数据传输，端口号在后面的编辑框设置。
“Version2.0Compatibility”用来选择加密模式，一般选择128bit模式即可。
在“Logging”选项中，选择日志的记录方式；最后的“IdleConnections”，如果选中的话，在指定时间内没有数据传输的话，连接就会自动断开。
“SerialNumber”页面用来管理SOS的license。
通过Add…按钮可以增加新的SerialNumber。
SOS中可以添加多个SerialNumber。
“Databases”页面用来添加SOS管理的VSS数据库。
点击Add…按钮可以添加数据库，添加对话框的上一个框填入VSS库的ini文件所在路径，下一个是数据库的别名，可以任意设置。
SOS可以同时管理多个数据库。
“Users”页面输入SOS中有效的用户和使用规则，注意，这里的用户和VSS的用户没有关系，VSS用户和SOS用户的关联在下面的“UserKeys”页面中设置。
要说明的是规则的描述：
“Users”中的一行对应一个规则，每行的开头是规则的编号，第二个字段是用户名，第三个字段是允许访问的网络段，第四个字段（取值为0、1、2）是控制访问允许以及访问是否使用加密方式的描述（0表示不允许访问；1表示要求加密访问；2表示允许使用加密或者不加密方式访问）。
例如，对第一行“0000admin192.168.3.0/241”表示这是第一个规则，规则内容是允许admin用户在192.168.3.0/24的网段上访问SOS服务器。
最后的1表示要求使用加密方式访问。
这里要说明的是“用户”的概念。
SOS没有自己的用户概念，SOS中的用户通过用户名称和VSS中的用户一一对应。
工程型软件项目的配置管理实例
（二）
——配置管理双枪将VSS＋SOS（下）
来源：
希赛网作者：
关河[2004/04/29]
“UserKeys”页面用来生成客户端访问控制的Key文件：
使用“AddKey…”按钮可以弹出“AddUserKey”的对话框。
该对话框的第一个输入框要求输入要增加的用户在VSS中对应的用户名；第二个输入框要求输入SOS服务器的IP地址，例如“202.100.68.88”，在局域网中可以设置为“192.168.1.1”；（注意，如果配置管理服务器同时具有局域网和广域网的IP地址，并且用户需要从局域网和广域网都可以访问SOS，则对同一个用户需要两个不同的Key文件。
在我们的实际工作中，我们只使用SOS进行Internet上的访问，在局域网内还是使用VSS，因此没有这个问题）。
下面的Expiration要求输入用户的过期有效时间期限，选择“KeyNeverExpired”允许用户永不过期。
输入完相应信息后，点击“OK”确认生成用户Key文件。
生成的用户Key文件保存在SOS安装目录下，文件名为[用户名].iky，注意保留此文件，SOS客户端在启动时需要首先导入一个key文件。
“WebProject”页面用于设置WebProject的发布路径：
在第一个编辑框中填入该工程在VSS中的路径，例如“$/WebProject1/test”，在下面的编辑框中输入发布的路径，例如“d:
\temp”。
发布路径也可以是在其他机器上的网络路径。
“Debug”页面是两个调试级别的选项：
这两个选项的具体含义在SOS的Manual中也没有明确提到，我们在实际运用中也没有发现该选项的具体作用，建议不选取。
“ExcludedFileTypes”页面设置不允许添加到VSS库中的文件类型：
添加的条目是文件后缀，具有在列表中的后缀的文件都不能被添加到VSS库中。
“PinSupport”页面用于设置是否允许PIN操作：
如果允许“PIN”操作，还需要指定ss.exe文件所在的目录。
设置完成后，需要重新启动SOS服务端，具体方法是在“服务”中启动相应服务：
启动服务完成后，服务端的安装设置就已经完成了，接下来我们介绍SOS客户端的安装和使用。
SOS客户端的安装和使用
SOS的客户端分为Windows版本、Solaris版本和Linux版本。
Windows版本的安装非常简单，直接执行安装程序就可以顺利安装。
Solaris版本的SOS客户端以tar形式发布，首先在Solaris上安装GTK和GLIB，然后展开安装程序到任意目录即可。
对Linux版本的SOS客户端，也需要首先安装GTK和GLIB，然后展开相应tar包到任意目录即可。
Solaris、Linux和Windows版本的SOS客户端运行界面都非常类似，下面以Windows版本为例说明其使用。
第一次运行SOS客户端时，系统会弹出一个对话框要求输入服务器和端口号。
这时用“Cancel”按钮取消，选择菜单项的“Tools”——“ImportEncryptionKey…”，导入服务端生成的Key文件：
导入完成后，选择菜单项的“File”——“ConnecttoServer…”，输入服务器IP地址和端口，如果连接成功，系统会给出可以连接的数据库列表，可以从列表中选择合适的数据库进行连接访问。
连接成功后，显示的主界面和VSS的基本一致，SOS的操作方式和VSS的也一样，具体可以参见VSS的文档。
下图是SOS的主界面：
当然，SOS在操作上也有一些和VSS不同的地方，下面列出这些不同点：
1、缺省设置下，SOS中每次登录不会主动刷新工程树和文件列表，需要用工具条上的刷新按钮进行刷新；
2、SOS的“Search”功能较VSS弱，只能查找CheckOut的文件；
3、SOS的Option设置项目很多，大部分都是SOS增加的为适应远程连接的设置项：
【小结】本章介绍了VSS、SOS的使用，重点是SOS的安装和使用方法。
SOS在使用上其实还有很多小技巧，在此不能一一列举，在sourcegear的网站上都能找到相关的资料。
在下一章中，我们将结合配置管理工具介绍配置管理规范的内容。
工程型软件项目的配置管理实例（三）
——配置管理规范
来源：
希赛网作者：
关河[2004/05/17]
配置管理规范
对于一个一般的项目来说，配置管理规范的内容至少需要包括以下的内容：
1、配置项及其命名规则；
2、配置库文件目录结构；
3、角色和权限定义；
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个（项目中使用的第三方产品），实际上，一个工程型的项目会大量使用第三方的软件（例如，我们的产品中就使用了IBM的MQSeries、Oracle、一些第三方的开发控件），对这些产品的管理至少可以解决三个方面的问题：
1、版本配合的问题：
大部分的第三方软件在升级之后，并不能实现二进制层面上的兼容，需要对原有的代码重新编译；甚至有的第三方软件在升级之后，API层面上的兼容性都做不到；因此，在工程实施的过程中，版本的配合问题是一个需要关注的问题；
2、发布的完整性问题：
一般来说，比较大型的第三方软件在发布过程中都不会有遗漏，但对一些小的第三方软件来说，比如我们使用的许多perl的CPan模块，如果在开发过程中没有有意识的进行管理的话，很容易就会发生遗漏；
3、在某些特殊条件下由于第三方软件的变化引起的基线变更：
这种情况极少会发生，但在我们以前的项目中，确实还遇见过。
一般是因为原来选型时使用的第三方软件不能满足要求，只能通过更换新的第三方软件，这就补课避免地需要变更基线（例如需求文档、设计文档等）；将第三方软件纳入配置管理的范畴可以更方便地管理基线的变更。
关于第三方软件产品配置项的管理还有一点需要说明：
由于第三方软件有可能会比较大，而且相对我们的项目来说，是很少会发生变更的（一般在一个项目过程中，不会采用不同的配置项的命名可以便于查找相关配置项。
配置项的命名包括两个方面的内容：
1、配置项标识：
在我们的项目中，一般使用“项目名_配置类别_配置项特殊标识”来命名。
下表
升级会员 