初学配置管理

文章来源：http://space.itpub.net/?uid-12231076-action-viewspace-itemid-193

最近在做公司的一个项目，在这个项目中，我除了负责测试外，还做CM（配置管理）和度量数据的采集工作，测试也属于品质保障部，我这个测试人员兼做配置管理，公司真会合理利用资源啊，就是不给加工资 。现在项目处于概要设计阶段，需求基线刚刚入库，我就来谈谈在需求开发这段时间做配置管理员的感受吧。

做过配置管理的人都知道，这个工作说难也难，说简单也简单。对刚刚涉足此领域的新人来说，如果没有CMMI配套的文档模板，真是不敢想象。我们虽然有一部分文档模板，但是很不完善，也没有成功的案例可以参考，痛苦的经历啊。

以前没有做过配置管理，VSS和CVS等常用的配置管理工具也不会用，现学现卖吧，文档管理我们选择的是VSS，按照项目组的意思首先建好了库，主要有：项目基线库，个人开发库，工程受控库和过程受控库。库的搭建过程就不说了，相信大家都会的。

下面就是添加用户和分配权限，照着配置库系统角色权限表一路分配下来。权限大致是：基线库：只有配置管理员，也就是我有所有权限，其他人只读；

个人开发库：PM和CM有所有的权限，其他人对自己的文件夹有除了删除外的所有的操作，开发人员之间的可以互相操作他们的文件夹里面的东西，除了不能删除外，PPQA和测试人员只能读别人的文件。

工程受控库：PM和CM拥有所有的权限，开发人员和PPQA只读权限，测试人员对测试部分的受控库有删除外的所有权限，对其他文件只读权限。

过程受控库：PM有所有的权限，CM对部分文件夹有所有的权限，对其他部分有删除外的所有权限，还有的只有只读权限，开发人员、 测试人员和PPQA对部分文件有删除外的其他权限，对另外的文件只有只读权限。

看着那个角色权限表，我才写出来的，呵呵 ，是不是很乱啊，可能是我的叙述不够清晰吧。先不管它。

接下来就是没有目的的管理，因为没有写配置管理计划，只是别人告诉做什么就做什么，每周要做的就是写配置管理周报和配置状态报告，还有就是备份数据，就这样过了快一个月的时间，此间也参加了几次培训和项目小组的会议，才知道配置管理原来不是想象的那么简单，还要监督很多东西，不是简单的统计和备份就完事了。

现在我发现了一些问题：文档提交的很乱，有时候统计时，发现文档被删除了，只知道删除了几个，不知道删除了哪几个，还有就是受控库里谁都往上提交，而且都可以Check out 修改，一个文档N多人改过，显然受控库就没有受控的意义了。我把这个问题在小组会议上反应了，经过讨论，权限重新划分。

新的授权如下：

• 受控库：权限不变，CM拥有所有的权限，其他人只读。
• 个人开发库：个人操作个人的文件夹，对其他人的只读。PM和CM可以操作所有人的文件夹。
• 工程产品受控库：CM有所有的权限。其他人只读。
• 过程产品受控库：CM有所有的权限。其他人只读。

这样是不是清晰多了，受控库也起到了控制的作用，我不知道这样算不算合理，但至少比以前的管理起来方便了，所有的要提交到受控库的文档由我一个人放入，统计起来也方便多了，按基线或变更提交，这样备份也有规律了，继续改进中......

现在我要做的工作也渐渐明确了，填写配置管理计划，这本来是在项目需求开始就要写好的，现在快速的补回来，配置项状态表：这个里面注明文档命名格式、过程域以及存放位置和需要提交时间，供项目开发阶段参照。以前备份都是自己决定，也没有备份记录和统计记录，现在需要填写日常备份申请表了。

工作明确后，什么事都觉得顺手了，以前由于权限混乱，文档提交的很乱，为了安全起见，不得不每天备份，增加了不少工作量，而且公司的备份服务器还没有安排好，要放到我自己的机子上，项目产出了很多的文档，数据量也越来越大，每天备份数据量实在太大了（我是采用的完全备份，VSS里的好像没有提供增量备份），不敢想象。现在好了，由于现在基线库和受控库都是我一个往里放，所以可以每周备份一次，也不怕丢失数据了，项目个人开发库，让他们自己去管理吧，我只要按照我的配置管理计划，到时候向他们要数据就可以了，是不是省事多了。

说到备份，我开始是用复制文件的方式，完全复制到本地，这样的好处是简单易操作，恢复的时候直接把备份拷回服务器，覆盖原来的数据即可，但是有数据量大的缺点。现在采用的是生成.ssa的备份文件，这样能节省很多空间。如果你也是生成.ssa格式的备份方法，恢复是要注意：

1.若原来作的是archive all the date的备份,并且没有将原project删除。
则："永久删除"原来的project再作恢复。

2.若原来作的 archive this version and older且你确认要回复到原来的版本
则："永久删除"原来的project再作恢复。（此时如果projects中有与其它projects共享的文档，最新的版本不被覆盖）

注：
1.第2种方法备份方法（archive this version and older）不推荐，除非你想省硬盘空间，那么请在备份后就将原来的版本删除这个选项打上，
以免恢复时麻烦。
2."永久删除"一个project可以在vss explore中进行，也可以在vss administrator中进行。

其实，CM说白了还是进行版本管控，至于怎么管控，个人的方法会不同，但是目的都是一样。一般公司可能会用两天服务器，一台做项目人员开发库，另一台做受控库和基线库。采用这种方法，就要求配置管理员每次从项目开发库取出来数据，自己的工作台起到中介作用，这种情况下，就可以在自己工作台上建立和库一样的目录，可以直接Get from 项目人员开发库和受控库到本地，以后需要更新的内容直接Check out到本地然后在Check in
进受控库。我们是受控库，基线库和项目人员开发库在一台服务器上，但是操作类似。我认为有条件还是把受控库和项目人员开发库分开，出于安全考虑，放两台服务器上更好管理，这样权限管理变的更简单。

看到一篇资料上介绍如何建立一个相对"安全"的VSS数据保护体系，自己整理了一下，供大家参考。

1.设一个安全文件夹与数据库目录平行（比如库在d:/doc/vss/aaa,则该目录设置为d:/doc/vss/lock）,将此目录设为隐藏,普通组员的权限设为可读

写但不能列目录。不能通过浏览器直接访问该目录，以防误删除。

2.VSS库所在的目录共享不变，但只保留srcsafe.ini文件，其它的一切移入上述的安全文件夹中。(创建d:/doc/vss/lock/aaa,容纳原aaa中文件及子文件夹)

3.在文件srcsafe.ini中，将路径和文件指向实际的内容（加相对路径，比如原来是Data_Path = data, 现在改为../lock/aaa/data，其它类推）。

srcsafe.ini改好后作一个备份，用以损坏后恢复。

4.在上述安全目录中加入一随机取文件名如（asdhfn3.7d）,对该文件的读取和写入进行系统的监控（观察是否有非法访问）

5.这个安全体系并没有排除硬件的故障以及他人用administrator的权限进行破坏的情况，所以定期备份还是需要的。

归纳一下，现在已经完成和正在完成的文档有：

1.  
   1. 配置状态报告
   2. 日常备份申请
   3. 配置管理计划
   4. 配置管理周报
   5. 配置库系统
   6. 配置项状态表

有了这些表的规范，我相信后面的配置管理应该会更明确了。

现在需求阶段的基线已经发布，并通过了评审，进入概要设计和详细设计阶段，在项目中成长吧，进步是看的见的。