配置项变更流程
我们所说的配置项变更流程主要是针对配置项发生变化的控制，在我们的项目中分为两个部分，首先是对配置项新建、检入（CheckIn）和检出（CheckOut）的规定；其次是对入库的文件类型和大小的规定：
新建、检入、检出及破坏
1、 新建：即Add，除特殊情况外，一般不规定由谁来新建（只要有权限即可），但尽量指定每个project只有一人负责新建。
2、 检入：即check in，检入频率规定如下：
i. 在代码编写前，至少每周一次
ii. 代码编写阶段，至少每天一次
iii. 测试阶段以后，根据代码、文档的变动，只要当天有变动就要检入一次。
iv. 为配合检查、备份工作，需在检查备份周期前全部check in (不保持check out)并退出登录。详见“检查及备份”部分
3、 检出：即check out。原则上只对要修改的文档方可检出。
4、 破坏（Destroy）：一般情况不可以破坏文件、目录。
5、 如果是误操作，则可在一天内提交管理员处
6、 如果超过一天，则需要由项目经理同意，且管理员破坏前要备份。
7、 各阶段环境职责
关于VSS库内存放文件类型及大小的规定
1、 文件名及目录规定：以英文名字命名
2、 文件大小规定：最大不超过20M
3、 允许类型：
4、 表2.1中提至的文档类
5、 代码及脚本类及为配合编译需要的类库等
6、 以下类型不允许存放在VSS库中：
7、 备份数据
8、 安装程序、打包程序（zip\rar）
9、 超过20M以上的非代码类及开发文档类文件
10、 对于特殊情况或不确定情况，需向配置管理人员咨询后再加入
11、 对于不允许存放类型的配置类文件，可与配置管理员联络，随件附《说明清单》，以文件型式保存于服务器。
配置项发布
配置项发布是指配置项进行到一定的阶段（例如，里程碑阶段），需要对外发布时的规则。在我们的项目中，配置项发布是通过标签，即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、 一个好的执行人员是成功的关键；
一个好的执行人员的重要性怎么强调都不过分。所谓的一个好的执行人员应该具备这样的素质：
a) 对配置管理工作有较为深刻的理解；
b) 对使用的配置管理工具运用熟练；
c) 具有好的沟通能力，能和开发组长、开发人员以及其他干系人沟通；
d) 有好的执行力，对流程的执行能起到监督和推动作用；
e) 耐心细致，很多时候，细节决定了成败；
2、 好的工具能起到事半功倍的效果；
选择一个合适的配置管理工具绝对是必要的，我们在前面用了一章多的篇幅介绍我们使用的配置管理工具及其方案，事实证明，我们选择的配置管理工具对我们项目管理实施的效果是决定性的。
3、 在配置管理实施的初期，及时的指导起的作用是巨大的，甚至可以说是成功的主要因素；
对不熟悉配置管理的开发工程师来说，配置管理工作容易在一开始就让他们产生厌烦情绪，一点点使用上的不方便就会导致开发人员对配置管理的怨言，这个时候，及时的指导就显得非常重要了，我们在配置管理实施过程中，准备了《VSS操作手册》、《SOS简明操作手册》、《配置管理操作指导书》等手册，进行了三次的培训，并在实施过程中随时解决开发人员在使用配置管理工具中的问题。而且，在实施初期，我们以奖励为主，在一个月的时间内没有将配置管理工作作为考核内容。
4、 每周的配置状态检查非常重要；
在配置管理基本走上正规后，每周的配置状态检查是我们对配置管理执行效果的检查，一旦发现问题，会作为QA问题报告发出并要求限期改正。如果没有这个检查制度，配置管理工作很难持续受控。
〔后记〕
《工程型软件项目配置管理实例》这几篇文章是我们在项目的配置管理实施过程中的一些体会，和其他配置管理文章不同的是，这里我们给出的都是马上就可以应用的实践步骤。当然，每个公司的环境各有不同，同样的实践不可能在每个地方都能产生一样的效果，只是希望这一系列文章能给大家一些启发。
时间仓促，文章中有些地方可能还有未能表达清楚的地方，欢迎大家和我探讨。
我们所说的配置项变更流程主要是针对配置项发生变化的控制，在我们的项目中分为两个部分，首先是对配置项新建、检入（CheckIn）和检出（CheckOut）的规定；其次是对入库的文件类型和大小的规定：
新建、检入、检出及破坏
1、 新建：即Add，除特殊情况外，一般不规定由谁来新建（只要有权限即可），但尽量指定每个project只有一人负责新建。
2、 检入：即check in，检入频率规定如下：
i. 在代码编写前，至少每周一次
ii. 代码编写阶段，至少每天一次
iii. 测试阶段以后，根据代码、文档的变动，只要当天有变动就要检入一次。
iv. 为配合检查、备份工作，需在检查备份周期前全部check in (不保持check out)并退出登录。详见“检查及备份”部分
3、 检出：即check out。原则上只对要修改的文档方可检出。
4、 破坏（Destroy）：一般情况不可以破坏文件、目录。
5、 如果是误操作，则可在一天内提交管理员处
6、 如果超过一天，则需要由项目经理同意，且管理员破坏前要备份。
7、 各阶段环境职责
|
环境
|
阶段
|
负责人
|
职责
|
| 公司内部 | 编码前 | 开发人员 |
每周及需要评审前check in工作产品（包括版本发布说明）到VSS上 |
| 开发组长 | 每周 | ||
| SCM人员 | 每周统计 | ||
| 编码 | 开发人员 |
每天check in工作产品（包括版本发布说明）到vss上 | |
| 开发组长 | 每周检查 | ||
| 经理及组长 | 抽查及走读 | ||
| SCM人员 | 每周统计，检查代码风格 | ||
| 测试 | 开发人员 |
每天check in工作产品到vss上（如当天没有修改可以不进行check in） 以LABEL形式提交一个新版本给测试，附带版本发布说明 |
|
| 测试人员 | 对测试完成后的程序打LABEL | ||
| 发布后 | 开发人员 | 将新版本check in到vss,打测试LABEL,向测试人员提交申请 | |
| 测试人员 | 对测试完成后的程序打LABEL | ||
| SCM人员 | 对变更做好控制和记录，并发布 | ||
| 现场开发负责人 | 将发布后的产版本更新至现场，或指定人员进行 | ||
| 公司外部 | 编码 | 现场开发负责人 |
在无法通过sos连到公司vss的情况下，需要在现场建立配置库（文件方式或VSS等），做到基本的版本控制和备份。每周至少通过SOS提交一次至公司的VSS库中。 |
| 现场开发人员 | 每天check in工作产品到现场配置库（包括版本发布说明）。 | ||
| SCM人员 | 做好督促和监督工作，每周将现场开发负责人提交的现场版本更新到公司配置库（vss）。 | ||
| 测试 | 现场开发人员 | 每天check in工作产品到现场配置库（如当天没有修改可以不进行check in）。 | |
| 如已经回公司则每天check in工作产品到公司配置库vss（如当天没有修改可以不进行check in）。 | |||
| 每周通过SOS提交一个新版本给测试，打测试LABEL,附带版本发布说明(如没有更新可不提交) | |||
| 对测试完成后的程序打LABEL | |||
| SCM人员 | 做好督促和监督工作 | ||
| 发布后 现场调试 现场维护 | 现场开发负责人 | 在无法通过sos连到公司vss的情况下，需要在现场建立配置库（文件方式或VSS等），做到基本的版本控制和备份。每周至少通过SOS提交一次至公司的VSS库中。通过LABEL提交测试版本 | |
| 现场开发人员 | 对修改后的版本通过SOS check in 新版本到vss,打测试LABEL,向测试人员提交申请（由修改至提交测试人员不应超过三天） | ||
| 测试人员 | 对测试完成后的程序打LABEL | ||
| SCM人员 | 对变更做好控制和记录，并发布 | ||
| 做好督促和监督现场提交更新版本到vss。 |
1、 文件名及目录规定：以英文名字命名
2、 文件大小规定：最大不超过20M
3、 允许类型：
4、 表2.1中提至的文档类
5、 代码及脚本类及为配合编译需要的类库等
6、 以下类型不允许存放在VSS库中：
7、 备份数据
8、 安装程序、打包程序（zip\rar）
9、 超过20M以上的非代码类及开发文档类文件
10、 对于特殊情况或不确定情况，需向配置管理人员咨询后再加入
11、 对于不允许存放类型的配置类文件，可与配置管理员联络，随件附《说明清单》，以文件型式保存于服务器。
配置项发布
配置项发布是指配置项进行到一定的阶段（例如，里程碑阶段），需要对外发布时的规则。在我们的项目中，配置项发布是通过标签，即LABEL，来实现的。
|
阶段
|
触发事件
|
操作人
|
标签类型
|
打标签的级别
|
| 单元测试 | 单元测试完成，可以提交集成测试 | 开发人员 | FOR_TEST | 模块级 |
| 集成测试 | 集成测试完成，不通过（如通过进入系统测试阶段） | 测试人员 |
TESTED | 模块级 |
| BUG修改完成，可以提交测试 | 开发人员 | FOR_TEST | 模块级 | |
| 集成测试通过，可以提交系统测试 | 测试负责人 | TESTED | 模块级 | |
| 系统测试 | 系统测试完成后，不通过，（如通过进入系统测试阶段） | 测试负责人 | TESTED |
项目级 |
| BUG修改完成，可以提交测试 | 开发人员 | FOR_TEST | 项目级 | |
| 系统测试通过 | 测试负责人 | TESTED | 项目级 | |
| 验收测试 | 验收前的版本，可发布到现场安装 | 配置管理员 | LOAD |
项目级 |
| 验收后的版本，可发布的正式版本 | 配置管理员 | LOAD | 项目级 | |
| 现场维护 | 修改BUG后提交测试 | 维护工程师 | FOR_TEST | 模块级/项目级/文件级 |
| 测试通过与否 | 测试人员 | TESTED | 模块级/项目级/文件级 |
基线确立与变更
基线的确定在上一部分中已经说到过，我们的项目基线分为两类，一类是作为里程碑和其他工作依赖的基线（例如需求文档、设计文档等），另一类是开发过程中有必要保留的一种状态（例如代码过程中某个模块的一个有保留价值的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、 一个好的执行人员是成功的关键；
一个好的执行人员的重要性怎么强调都不过分。所谓的一个好的执行人员应该具备这样的素质：
a) 对配置管理工作有较为深刻的理解；
b) 对使用的配置管理工具运用熟练；
c) 具有好的沟通能力，能和开发组长、开发人员以及其他干系人沟通；
d) 有好的执行力，对流程的执行能起到监督和推动作用；
e) 耐心细致，很多时候，细节决定了成败；
2、 好的工具能起到事半功倍的效果；
选择一个合适的配置管理工具绝对是必要的，我们在前面用了一章多的篇幅介绍我们使用的配置管理工具及其方案，事实证明，我们选择的配置管理工具对我们项目管理实施的效果是决定性的。
3、 在配置管理实施的初期，及时的指导起的作用是巨大的，甚至可以说是成功的主要因素；
对不熟悉配置管理的开发工程师来说，配置管理工作容易在一开始就让他们产生厌烦情绪，一点点使用上的不方便就会导致开发人员对配置管理的怨言，这个时候，及时的指导就显得非常重要了，我们在配置管理实施过程中，准备了《VSS操作手册》、《SOS简明操作手册》、《配置管理操作指导书》等手册，进行了三次的培训，并在实施过程中随时解决开发人员在使用配置管理工具中的问题。而且，在实施初期，我们以奖励为主，在一个月的时间内没有将配置管理工作作为考核内容。
4、 每周的配置状态检查非常重要；
在配置管理基本走上正规后，每周的配置状态检查是我们对配置管理执行效果的检查，一旦发现问题，会作为QA问题报告发出并要求限期改正。如果没有这个检查制度，配置管理工作很难持续受控。
〔后记〕
《工程型软件项目配置管理实例》这几篇文章是我们在项目的配置管理实施过程中的一些体会，和其他配置管理文章不同的是，这里我们给出的都是马上就可以应用的实践步骤。当然，每个公司的环境各有不同，同样的实践不可能在每个地方都能产生一样的效果，只是希望这一系列文章能给大家一些启发。
时间仓促，文章中有些地方可能还有未能表达清楚的地方，欢迎大家和我探讨。
