思步网

查看: 106068|回复: 59
打印 上一主题 下一主题

[其他] ClearCase在实际项目中的应用

  [复制链接]
本帖最后由 蝴蝶 于 2012-4-13 15:37 编辑

1 统一标识工件,并存入安全的配置库6
                        进行配置管理时,我们需要对那些将处于版本控制下的工件进行统一标识。就配置管理工具而言,标识意味着能够快速方便地查找和确定项目或系统的工件。如果你曾参与或管理过一个没有配置管理,或配置管理做的很差的项目,你会发现标识正确的文件的正确的版本是多么的困难,因为到处都有拷贝。最坏的情况,丢失或错误标识工件的版本会导致项目的失败,那么由于丢失的部分延迟了系统的提交,要么因为错误的部分降低了系统的品质。
                        配置项的标识既包括用户管理和设计系统的工件(例如项目计划、设计模型等),也包括用于实现系统设计的工件(如源代码、库、可执行文件等)。这两种类型的配置项都很容易标识,也不容易遗漏。这里我们要强调的是在实际项目中配置项标识中,很容易忽视和遗漏的一类配置项。这类配置项就是项目的一些支撑信息,例如基础数据、配置参数、建表文件,操作系统基础参数等。很多项目不认为这类信息也应该作为配置项纳入配置库进行配置管理。试想,假设生产系统异常崩溃,那么项目组拿什么数据去恢复生产环境,因为仅有源码是不够的。所以,生产系统运行支撑的所有信息,都应该作为配置项纳入配置库进行配置管理。
                        除了统一标识、完整标识所有的配置项外,对于不同类型的配置项,我们还需要明确不同的文件保存方式。对于设计系统的工件(如项目计划等)、实现系统设计的工件(如源码等),这些配置项都有特定的文件格式,所以在配置库中的保存没有什么特别。但是对于建表文件、配置参数等支撑信息,则需要明确文件保存方式。例如,系统公共配置参数,这些是存放在数据库中的,如何对这些文件进行管理和控制,如何在配置库中保存这些文件,这是需要配置管理员和项目关系人经过分析和讨论后明确下来的。例如,在某项目中,根据项目实际情况,笔者针对各种类型的配置项,定义了相应的文件保存方式(见图一)。 5 m: n& Q5 s$ c0 S- g$ A+ q
                        图一不同类型配置项存放方式7 S
                        组织工件并能够定位这些工件还是不够的。针对那些关键资产,其配置库还应该具备可容错和可复制能力。对于所有的软件资产,配置库是潜在的故障集中点,因此配置库必须是可容错和可复制的。
                        除此之外,我们还应该有适当的过程对配置库做备份和灾难恢复。如果没有完备的备份过程,即使我们将所有的配置项都纳入配置库了,但是一旦发生配置管理系统崩溃的情况,我们一样将丢失公司的软件资产,所以,定义适当的备份过程,是保证工件存入安全配置库的一个很重要的环节。
                        1.1 配置库的创建
                         为了将标识出的工件存入安全的配置库,我们首先需要创建配置库。
                        在创建配置库前,我们需要根据不同的管理需要,设置不同的库,例如:编辑库、测试库、产品库等。有的公司则划分为产品发布库、产品受控库、产品研发库。不管采用哪种划分方式,实际都是类似的,都是依据项目开发管理需要来进行划分的。假设我们分为编辑库、测试库、产品库,那么这些库分别对应着项目成员工作区、测试人员获取测试程序的工作区、产品正式发布版本的存放位置。
                        在传统手工配置管理方式下,这些不同的配置库之间很多都是通过文件拷贝方式实现各个库的管理。这种方式存在两个问题:一是由于这些配置库之间不是孤立的库,而是相互联系的,它们之间不能通过简单的文件拷贝方式复制;二是,每个配置项在项目的配置库中应该只有一份,这种采用文件拷贝的方式违背了配置管理系统中配置项的唯一性要求。在ClearCase中,我们可以使用分支或者流的方式进行映射。
                        针对不同的配置库,我们需要有不同的安全设置或权限控制。例如,测试库和产品库,只能由配置管理员进行成果的提交;而编辑库作为项目成员的工作区,则不进行权限控制。但是假设项目由多个开发商负责开发,那么对于编辑库,我们则需要针对不同开发商就开发模块/子系统进行相应的权限控制。
                        1.2 配置库的备份:
                        进行配置管理时,我们需要对那些将处于版本控制下的工件进行统一标识。就配置管理工具而言,标识意味着能够快速方便地查找和确定项目或系统的工件。如果你曾参与或管理过一个没有配置管理,或配置管理做的很差的项目,你会发现标识正确的文件的正确的版本是多么的困难,因为到处都有拷贝。最坏的情况,丢失或错误标识工件的版本会导致项目的失败,那么由于丢失的部分延迟了系统的提交,要么因为错误的部分降低了系统的品质。
                        配置项的标识既包括用户管理和设计系统的工件(例如项目计划、设计模型等),也包括用于实现系统设计的工件(如源代码、库、可执行文件等)。这两种类型的配置项都很容易标识,也不容易遗漏。这里我们要强调的是在实际项目中配置项标识中,很容易忽视和遗漏的一类配置项。这类配置项就是项目的一些支撑信息,例如基础数据、配置参数、建表文件,操作系统基础参数等。很多项目不认为这类信息也应该作为配置项纳入配置库进行配置管理。试想,假设生产系统异常崩溃,那么项目组拿什么数据去恢复生产环境,因为仅有源码是不够的。所以,生产系统运行支撑的所有信息,都应该作为配置项纳入配置库进行配置管理。5
                        除了统一标识、完整标识所有的配置项外,对于不同类型的配置项,我们还需要明确不同的文件保存方式。对于设计系统的工件(如项目计划等)、实现系统设计的工件(如源码等),这些配置项都有特定的文件格式,所以在配置库中的保存没有什么特别。但是对于建表文件、配置参数等支撑信息,则需要明确文件保存方式。例如,系统公共配置参数,这些是存放在数据库中的,如何对这些文件进行管理和控制,如何在配置库中保存这些文件,这是需要配置管理员和项目关系人经过分析和讨论后明确下来的。例如,在某项目中,根据项目实际情况,笔者针对各种类型的配置项,定义了相应的文件保存方式(见图一)。
                         ; E& r2 d% @) l# L8 b7 Y3 M
                        图一不同类型配置项存放方式"
                        组织工件并能够定位这些工件还是不够的。针对那些关键资产,其配置库还应该具备可容错和可复制能力。对于所有的软件资产,配置库是潜在的故障集中点,因此配置库必须是可容错和可复制的。
                        除此之外,我们还应该有适当的过程对配置库做备份和灾难恢复。如果没有完备的备份过程,即使我们将所有的配置项都纳入配置库了,但是一旦发生配置管理系统崩溃的情况,我们一样将丢失公司的软件资产,所以,定义适当的备份过程,是保证工件存入安全配置库的一个很重要的环节。



上一篇:SVN检索功能?
下一篇:CVS和VSS的比较
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 转播转播 分享分享 分享淘帖 支持支持 反对反对
回复 论坛版权

使用道具 举报

CC功能太大,很难搞啊!
[发帖际遇]: 水一方 在论坛发帖时没有注意,被小偷偷去了 1 (金) 金币. 幸运榜 / 衰神榜
是爷们的娘们的都帮顶!
看帖要回,回帖才健康,在踩踩,楼主辛苦了!
纯粹路过,没任何兴趣,仅仅是看在老用户份上回复一下
鼎力支持!!
好帖是需要鼓励的~
很有借鉴意义,先收藏了,谢谢楼主。
非常好,顶一下占位编辑
我是个凑数的。。。
看起来好像不错的样子
这么强,支持楼主,佩服
学习下我只是路过,不发表意见……
很有借鉴意义,先收藏了,谢谢楼主。
看起来好像不错的样子
您需要登录后才可以回帖 登录 | 注册

本版积分规则



思步组织思步科技|思步网|火花学堂|思步文库|思步问答|思步英才|天下心
© 2007 思步网 浙ICP备10212573号-4(首次备案号:浙ICP备07035264号)|邮箱:service#step365.com(将#换成@)|服务热线:0571-28827450
在线培训课程|求职招聘|思步文库|官方微信|手机APP|思步问答|微博平台|官方QQ群|交流论坛|软件工程透析|关于我们|申请友链|
点击这里给我发消息     点击这里给我发消息
思步 step365 过程改进 CMMI中文 质量保证 质量管理 流程体系 需求跟踪矩阵 敏捷开发 Scrum 软件度量 项目评审 全员改进 流程管理 人力资源 6sigma 信息安全 ISO27001认证 IT服务管理 ISO20000认证 ISO9000认证 软件测试 SQA 配置管理 IPD 软件工程 PMP认证 PMP试题 PMBOK中文 精益研发 agile 顾问式管理培训
返回顶部