初学配置管理

发表于:2007-10-12来源:作者:点击数: 标签:配置管理
最近在做公司的一个项目,在这个项目中,我除了负责测试外,还做CM(配置管理)和 度量 数据的采集工作,测试也属于品质保障部,我这个 测试人员 兼做配置管理,公司真会合理利用资源啊,就是不给加工资 。现在项目处于概要设计阶段,需求基线刚刚入库,我就

最近在做公司的一个项目,在这个项目中,我除了负责测试外,还做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. 配置状态报告
    2. 日常备份申请
    3. 配置管理计划
    4. 配置管理周报
    5. 配置库系统
    6. 配置项状态表

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

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

刚开始接触配置管理,什么都不会,希望大家不要笑我,嘿嘿,有什么好的建议可以指导一下,非常感谢!

原文转自:http://www.ltesting.net