配置项变更流程

我们所说的配置项变更流程主要是针对配置项发生变化的控制，在我们的项目中分为两个部分，首先是对配置项新建、检入（CheckIn）和检出（CheckOut）的规定；其次是对入库的文件类型和大小的规定：

新建、检入、检出及破坏

1、 新建：即Add，除特殊情况外，一般不规定由谁来新建（只要有权限即可），但尽量指定每个project只有一人负责新建。

2、 检入：即check in，检入频率规定如下：

3、 检出：即check out。原则上只对要修改的文档方可检出。

4、 破坏（Destroy）：一般情况不可以破坏文件、目录。

5、 如果是误操作，则可在一天内提交管理员处

6、 如果超过一天，则需要由项目经理同意，且管理员破坏前要备份。

7、 各阶段环境职责

关于VSS库内存放文件类型及大小的规定

配置项发布

配置项发布是指配置项进行到一定的阶段（例如，里程碑阶段），需要对外发布时的规则。在我们的项目中，配置项发布是通过标签，即LABEL，来实现的。

基线确立与变更

基线的确定在上一部分中已经说到过，我们的项目基线分为两类，一类是作为里程碑和其他工作依赖的基线（例如需求文档、设计文档等），另一类是开发过程中有必要保留的一种状态（例如代码过程中某个模块的一个有保留价值的snapshot）。对这两种不同的基线，其影响的范围不同，确立和变更方式也不一样。

我们项目的基线变更控制委员会由客户代表、产品经理、项目经理以及技术经理组成，对发布的里程碑类基线的变更必须由变更控制委员会确认并由QA进行变更记录，所有被变更影响的配置项都需要重新同步后再次发布；而对于仅仅作为工作状态保留的基线，一般只需要建立基线的小组确认更改并在QA进行记录即可。

检查与备份

1、 检查：

根据VSS白皮书建议，要定期检查数据的正确性。故VSS库管理员应每周检查一次，流程如下：

a) 开发人员于每周五下午5:30前check in（(不保持check out)）并退出登录

b) VSS库管理人员用analyze工具检查VSS数据库，操作如下：

在dos命令行中输入：analyze –f –d –c –v4 c:\vss\data

其中“c:\vss\data”为vss库的数据目录

2、 备份：

a) 每天增量备份，通过windowsNT以上自带的备份工具进行增量备份，备份以硬盘存放即可。

b) 每周全备份：每周检查完毕之后，对VSS数据库进行全备份，建议以光盘介质备份。

配置管理实施后记

应该说，这次我们对项目的配置管理实施是非常成功的，在整个开发过程中，基本没有出现因为配置管理的问题导致的对开发进度的延误。当然，在开发过程中也发生了由于需求变化导致基线变更引起开发进度的延迟，不过这不应该算作是配置管理的失误，因为作为配置管理来说，只能尽量保证基线变更不会导致项目失控。

总结我们这次的配置管理实施工作，除了这几篇文章中讲到的需要注意的问题外，我觉得有一些应该算做是决定实施成败的关键因素：

1、 一个好的执行人员是成功的关键；

一个好的执行人员的重要性怎么强调都不过分。所谓的一个好的执行人员应该具备这样的素质：

2、 好的工具能起到事半功倍的效果；

选择一个合适的配置管理工具绝对是必要的，我们在前面用了一章多的篇幅介绍我们使用的配置管理工具及其方案，事实证明，我们选择的配置管理工具对我们项目管理实施的效果是决定性的。

3、 在配置管理实施的初期，及时的指导起的作用是巨大的，甚至可以说是成功的主要因素；

对不熟悉配置管理的开发工程师来说，配置管理工作容易在一开始就让他们产生厌烦情绪，一点点使用上的不方便就会导致开发人员对配置管理的怨言，这个时候，及时的指导就显得非常重要了，我们在配置管理实施过程中，准备了《VSS操作手册》、《SOS简明操作手册》、《配置管理操作指导书》等手册，进行了三次的培训，并在实施过程中随时解决开发人员在使用配置管理工具中的问题。而且，在实施初期，我们以奖励为主，在一个月的时间内没有将配置管理工作作为考核内容。

4、 每周的配置状态检查非常重要；

在配置管理基本走上正规后，每周的配置状态检查是我们对配置管理执行效果的检查，一旦发现问题，会作为QA问题报告发出并要求限期改正。如果没有这个检查制度，配置管理工作很难持续受控。

〔后记〕

《工程型软件项目配置管理实例》这几篇文章是我们在项目的配置管理实施过程中的一些体会，和其他配置管理文章不同的是，这里我们给出的都是马上就可以应用的实践步骤。当然，每个公司的环境各有不同，同样的实践不可能在每个地方都能产生一样的效果，只是希望这一系列文章能给大家一些启发。
时间仓促，文章中有些地方可能还有未能表达清楚的地方，欢迎大家和我探讨。