• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

ClearCase迁移中的一些经验

发布: 2008-9-23 14:40 | 作者: 崔秉正 | 来源: IBM | 查看: 1043次 | 进入软件测试论坛讨论

领测软件测试网

1 简介

1.1 目的
本文的目的是介绍某公司在将软件资产从其他配置管理工具迁移到IBM Rational公司的ClearCase UCM配置管理解决方案的一些经验。

1.2 概念
在使用ClearCase之前,必需理解某些概念:

  • Element 纳入配置管理的包括版本信息的配置项,包括文件与目录。
  • VOB Version Object Base,存放配置项的库。
  • UCM Unified Changed Management的缩写,统一变更管理模式
  • Activity Activity是ClearCase UCM模式中的一个概念,通过变更集(Change Set)跟踪完成一项开发任务所引起的所有配置项的变更。在UCM模式下所有的Check Out、Check In、Add to Source Control等引起配置项发生变化的操作必须关联到一个Activity。
  • Change Set Change Set记录了Activity所关联的所有的配置项的版本变更,每个Activity都有一个Change Set。
  • Component 可以理解为一些代码、文档、Model等按一定的目录结构组织成的完成某些功能的可以重用的集合。这是UCM所引入的概念,Component与UCM Project相关联,UCM Project所管理的所有的Element必定从属于一个Component,每个UCM Project至少有一个Component。
  • Deliver UCM的概念,是一个从开发流向UCM Project集成流或其他开发流提交工作的一个动作。
  • Development Stream UCM的概念,可以理解为一个独立的开发环境,包含了在这个开发流上的Activity与修改的配置项的版本,UCM通过开发流简化了并行开发的配置管理工作。
  • Dynamic View Dynamic View是对VOB的一个动态视图,VOB的变化会及时反应到Dynamic View上,每个Dynamic View都关联到一个Stream上,在Dynamic View上会有一些View的私有文件,这些View私有文件不会被同一个Stream上的其他View所见到。
  • Integration Stream UCM的概念,可以理解为项目的主干,每个开发流都是集成流的一个分支,在开发流上完成工作后,再提交到主干,项目的Build环境建议采用集成流
  • Project 是ClearCase UCM的一个概念,包含了配置管理所需要的一些配置信息,如果Component、Baseline,Stream等,每个Project都有一个Integration Stream。
  • Project VOB(PVOB) 是存储UCM所需要的一些特殊的信息,如Proejcts,Stream,Activity及Change Sets等,一个PVOB可以包含多个Project的信息, Project的信息必须保存在PVOB中。
  • Rebase UCM模式的一个操作,让当前Stream的View的内容与Integration Stream推荐基线同步。
  • Snapshot view Snapshot View是对VOB的一个静态视图,将相关的VOB的选定的版本下载到本地保存,需要经常进行Update View操作以保证与关联的stream同步。
  • Add to Source Control 执行将选定的文件或目录纳入ClearCase管理的动作,需要注意的是,如果要在某一目录下添加文件或目录,必须先将它所在的目录先Check out,再在该目录下执行Add to Source Control动作,而后再对当前目录执行Check in;如果正确执行完成后,该文件与目录后的类型会变为File element Version或Directory Version,如果没有将当前目录Checkout就执行Add to Source Control,则在执行完成后文件的类型还是View-private File或View-private Directory,在这种情况下,该文件或目录实际上没有纳入配置管理。

2 计划与准备

2.1 计划
配置管理切换大至可以划分为以下几个阶段:计划,准备,配置库的迁移,正式使用。

配置管理切换计划的主要内容包括进度、资源等。

项目的规模与所处的阶段不同,则配置管理切换所需要的时间也不同。一个20人左右,开发进度约达到计划的一半,代码量达到50K左右的项目,从开始计划到配置管理完全切换到ClearCase,最少需要3-4周时间。如果盲目的追求进度,想在1-2周内切换完成,则可能在切换后产生一系列后遗症,如版本丢失、版本错误甚至可能会有部分项目组成员抵制,从而使项目开发进程中部分工作不能纳入配置管理之下。

进度安排建议:根据项目的情况用5-15个工作日进行准备,配置库的迁移需要5个工作日左右的时间,配置管理工程师要用5-10个工作日的跟进以使项目组成员熟悉并不再需要帮助。

任何计划都有一个前提:资源,不同的资源会导致不同的进度与成本。在配置管理切换中三类资源非常重要:经过培训并且有ClearCase经验的配置管理工程师;经过培训并了解ClearCase UCM概念的项目经理与架构师;Rational工程师的及时支持。

配置管理工程师在这3-4周时间内要没有其他的任务的打扰,全部的时间应用于该项目的配置切换;每个项目在配置切换的准备阶段如果有Rational工程师的现场支持会少走许多弯路。

为了更好的完成工作,配置管理工程师必须经过系统的ClearCase的培训,同时为了提高配置管理工程师的能力,建议在内部建立一个独立的试验环境,可以让配置管理工程师从安装配置Server开始,进行ClearCase的各种功能的操作试验,以获得经验。

2.2 准备
如果决定应用ClearCase,好的计划与充分的准备会起到事半功倍的效果。一个项目从启动就应用ClearCase则相对于从其他配置管理解决方案迁移到ClearCase在准备上要容易的多,包括多个版本分支的产品的配置迁移则更加困难,如果准备不充分,可能会造成多次反复、严重降低工作效率,甚至可能会造成版本错误等严重后果。

首先,要决定是应用ClearCase UCM还是Base ClearCase,UCM模式是基于Base ClearCase应用Activity管理变更的一种模式。如果项目组全部在UNIX上进行开发,比较熟悉CVS,对命令行及Shell很熟悉,项目团队配合时间较长,有专职配置管理工程师,建议应用Base ClearCase,但是需要自行开发脚本,以利于项目组成员的使用;跨平台项目、配置管理工程师是与其他项目共用的、需要对项目的进度与活动有较高的透明度等建议应用UCM模式。本文主要探讨UCM模式。

在准备的时候要确定当前项目与其他的项目的关系,以确定PVOB的建立,如果项目和其他项目的关系不是很紧密,建议创建一个独立的PVOB。因为一般PVOB不占用过多的资源。

2.2.1 配置模式

PVOB建立完成后,要根据项目的实际情况确定项目的开发模式,这里给出一些建议。

2.2.1.1 共享流模式

项目只有一个单独的集成流,没有开发流。适用于调研项目或规模较小,且目标单一,不会同时有多个变更存在的项目。比较大的项目也可以在实际项目的初始阶段建立一个UCM Project,采用共享流模式,在需求完成后,在这个Project的Component上建立Final基线,在这个基线上建立一个新的多开发流模式的UCM Project进行设计与编码。

优点:控制简单,如果设置的是Dynamic View,每个人的修改,其他人可以立即看到,不需要deliver,对有大量文档的项目较适合;不需要针对Deliver及Rebase设置大量的基线,配置管理人员的工作相对较少;同时项目配置管理的Policy也比较简单,不需要考虑太多。

缺点:如果同时支持多个不同的客户或同时有多个变更,这些变更之间互相影响,则会产生开发的混乱。

在Clearcase中共享流模式也支持同时多个用户对同一文件进行Check out操作,并在Check in时进行归并。但是如果多人对一个Element进行Check out操作时,只有一个人可以应用Reserved checkout,其他的项目组成员只能进行Unreserved Checkout。Reserved Checkout保证了开发人员是在最新的一个版本上进行Checkout,只有在Reserved Checkout的人Check in之后才可以Check in并进行归并。Reserved与Unreserved的区别可见图一。


图一:两种Check-Out方式

2.2.1.2 多开发流模式

项目中有多个不同的开发流,每个开发流都是一个独立的分支,如果项目需要还可以建立多层次的分支,支持并行开发,适于超过10人,较复杂的项目。如果项目极复杂,可以分为多层开发流与集成流,如图二。优点:可以并行开发,每个Stream都相当于一个独立的开发环境,每个人之间的工作不会互相产生干扰;可以通过Policy的设置更好的进行配置管理。

缺点:不同的Stream之间的Deliver与Rebase会产生问题;在merge时也有可能会产生问题,而且对Word等二进制文件的merge支持不好;在修改完成之后,每个Stream上的修改只有deliver与Rebase才能被其他的stream应用,不能及时反映变化;Policy的设置较复杂。

在多开发流模式下可以根据需要将某个stream设置为只读模式。

建议:可以根据需要建立一个多开发流模式的Project,但是在初期阶段不设立开发流,在进行详细设计阶段后再建立相应的开发流。


图二:多开发流模式示例

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: clearcase ClearCase 经验 迁移

31/3123>

关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备2023014753号-2
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网