注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

中吴南顾惟一笑

成功法则就是那19个字

 
 
 

日志

 
 

ClearCase项目管理(转)  

2009-10-13 09:53:50|  分类: R&D |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

1、 ClearCase 简介

ClearCase(以下简称CC)是一种配置管理工具,由 Rational公司开发,是开发小组用来跟踪、管理软件开发过程各个工件的配置管理系统, ClearCase可以协助开发组织更好地管理软件开发进程。

ClearCase可以和Rational公司的其他软件紧密结合,例如 UCMClearQuest等等。 ClearCase包括两套:ClearCase LT ClearCase (MultiSite) 前者可以用于在同一个局域网的开发小组,适合于中小型开发组织;后者则适应于分布于不同地理位置、不同局域网的开发小组,适合于大型的开发组织。ClearCase LT由ClearCase LT Server和ClearCase LT Client两个部分组成,其中服务器部分负责数据的集中管理;客户端部分则安装在各个需要使用ClearCase服务的机器上,属于典型的Client/Server结构。ClearCase LT Server采用VOB (Versioned Object Base)存储配置管理数据,用户通过视图(VIEW)的方式获取VOB中存储的数据。

2、 ClearCase 中的概念、术语

Element

 纳入配置管理的包括版本信息的对象,包括文件和目录以及metadata等。

VOB

Versioned Object Base,存放Element所有版本数据以及其他CC配置信息的库。

PVOB

Project VOB,用于存放UCM项目对象(比如Project,Activity)的VOB。一个UCM项目必须存放于一个PVOB中,而一个PVOB可以存放一个或者多个UCM项目。

UCM

Unified Changed Management的缩写,统一变更管理模式。在CC中有两种项目管理的模式:Base ClearCase UCM。在UCM模式下所有的Check OutCheck InAdd to Source Control等引起对象发生变化的操作必须关联到一个Activity,因此UCM模式通过Activity来管理和控制对象的版本更新(即通过Stream(流)和Activity(活动)管理项目)。而Base ClearCase模式下,由于没有Activity的概念,上述操作都将直接定位到一个特定的对象,所以是一种基于Element和Branch的管理方式。UCM方式对基线的管理更加自动化,更加有利于并行研发模式,一般情况下我们可以使用CCUCM模式达到项目管理的需求。

Activity

ActivityClearCase UCM模式中的一个概念。一个Activity包括一个标题和一个变更集(Change Set),标题用于简要描述Activity,变更集集中跟踪与此Activity相关的所有Element的版本变更。

CHECK-IN& CHECK-OUT
ClearCase通过Check-in和Check-out的方式实现配置管理。Check-out一个文档 时,ClearCase就会在视图中创建该文档的一个可编辑的版本,能够对该文档进行修改;Check-in一个文档时,ClearCase就在VOB中 创建该文档的一个新的永久的版本,本地视图中对应的文档就会变成只读属性,无法修改。

Component

在一个UCM项目中由一些相关的文件或者目录组成的一个ClearCase对象。一个项目至少包含一个Component,而一个Component也可以由多个项目共享。

Baseline

基线就是表示一个Component到达某个开发阶段(特定时刻)的标识,这个标识包含了Component内部各个Element所处的特定版本。Project可以通过配置它所包含的所有Component的基线来标识它目前所处的开发阶段。在UCM中,要求必须使用基线。当加入项目的时候,工作区的内容为项目推荐基线的内容。这种方法保证开发组成员都从相同的共享文件集开始。

VIEW

一个ClearCase对象,能够为用户提供完成项目修改工作的工作空间(Work Space)。VIEW是通过一定的规则从VOB中选择各个元素特定版本的集合来形成一个工作空间,用户通过VIEW存取、修改其中的元素。有两种类型的视图:快照视图和动态视图。

1.         视图有两种类型:快照视图(snapshot view)及动态视图(dynamic view)。快照视图是将CC服务器中的视图内容拷贝到开发人员的机器中,开发人员需要经常与服务器同步以保持数据的一致性,快照视图的好处在于开发人员不必一直通过网络与CC服务器保持连接;动态视图则不拷贝文件到本地,使用MVFS(multiversion file system)将数据组织进一颗目录树中,这就要求开发人员一直保持与服务器的网络连接。一般来讲,由管理员决定选用哪种视图。

2.         开发人员的开发涉及到两个视图:开发视图和集成视图。开发视图用于开发人员的开发过程,开发人员在开发视图中完成软件的开发、修改、提交等工作;集成视图的作用是存放开发人员完成的工作,使得开发人员可以通过该视图中的内容对其开发进行验证。

Stream

Stream记录了在Project中所有工作空间(私有工作区和共享工作区)的活动历史,Stream同时也指定了某个时刻工作空间应该能够获取和使用的各个元素的版本。Stream分为Integration stream(集成流)和Development streams(开发流),一个UCM项目中只能有一个集成流,但可以包含多个开发流(项目组成员和开发流是一一对应的关系)。集成流记录了项目中公共的元素及其状态,而开发流记录了各个项目组成员私有的元素及其状态。

以下操作将修改一个Stream的配置:

1).在工作视图中进行“签入”操作,一个Stream可以对应多个视图

2).Rebasing操作,它将用更新版本的元素更改Stream的配置

3).Delivering操作,交付将当前流的修改反映到目标流中。就个人理解交互一般用于将开发流中的变更反映到集成流中以便所有项目组成员都能看到这些变更;

4).Delivering baselines,交付基线。

ActivityViewStream的理解

开发人员需要相互隔离的工作环境以隔离彼此的工作,避免其他组成员的变更潜在地影响其工作的稳定性。ViewCC中的工作平台,大部分的工作都是项目成员在其View中完成,这些工作有些反映成ActivityStream记录了与他相关的View的所有工作历史。开发视图是开发流的工作平台,项目组的每个成员各自都有一个开发流,但可以有多个开发视图。开发人员在任意一个开发视图中的工作都将被该开发人员对应的开发流记录。集成视图是项目的集成流的工作平台,它是一种特殊的开发视图,因为任何一个项目成员在集成视图中的工作都将被项目的集成流记录,而集成流在一个UCM项目中只有一个。Rebasing操作和Delivering操作是两个相对的操作,Rebasing操作用于使得集成流中的配置反映到开发流中,而Delivering操作将开发人员的开发流中的配置反映到集成流中以便其他成员能够共享。

Stream是一个从上到下贯穿整个开发过程的一种历史记录,而View是对Stream的某个阶段(一般来说是最近的)的一个片段,在这一个片段中,项目组成员可以通过“签入”Activity来使得Stream变化。BASE ClearCase使用分支(Branch)来保证并行开发。每一个元素都有一个主分支,代表开发的主线,有多个子分支,分别为独立的开发线。在UCM中,在分支基础上对其在更高层次上进行了抽象和封装,从而形成了一个新概念——流(stream)开发人员无需直接操纵分支,也不支持分支上再建分支。 他们在自己独立的分支上工作,互不干扰。流表示一个私有或共享的工作空间,它定义了项目版本的统一配置并在UCM项目中的隔离和有效协作之间提供了一种平衡。

3、 ClearCase LT工作原理

上面提到过ClearCase LT管理项目有两种模式,其中UCM模式是更有效和便捷的方法。(参考《Software Configuration Management Strategies and IBM? Rational? ClearCase? Second Edition A Practical Introduction》“3.5. ClearCase UCM Process Overview”)说明了在一个开发团队中几个角色运用ClearCase UCM协作开发一个项目的流程。其中ArchitectConfiguration ManagerProject ManagerDeveloperIntegrator依次代表架构师、配置管理员、项目管理员、开发人员、集成人员。从图中我们可以了解,UCM模式下的项目开发是一个迭代的过程,主要工作集中在项目管理员、开发人员、集成人员,他们承担起项目开发、调试、集成等一系列工作。下面我们依次对管理员、开发人员、集成人员在UCM模式中的工作任务做一个简要的介绍。

Project Manager

依照项目职责和工作的划分,项目管理员的职责包括:

1.         为项目创建或者设定Component

2.         创建UCM项目

3.         建立UCM项目管理的策略,包括对象的可访问性等

4.         计划和分配项目工作

5.         监视项目进展和状态

ClearCase的文档(参考“Workflows for Managing Projects with UCM”)中对项目管理员的职责有不同的划分,主要的区别在于“为项目创建或者设定Component”被认为是项目集成人员的工作。

Developer

开发人员在项目建立之后就可以加入项目了,加入项目将会在UCM中创建各自的开发流以及开发视图,开发人员的主要职责包括:

1.         加入到项目

2.         根据项目管理员分配的工作对在各自的开发视图中对项目进行修改

3.         提交开发流中修改到集成流

4.         在集成人员提升项目的基线之后更新各自的开发流和开发视图,并进入到下一个迭代

ClearCase的文档(参考“Software Development with UCM”)中对开发人员的职责也有一个大同小异的描述,这一描述突出了ActivitiesUCM中的作用

Integrator

项目开发人员提交了新的修改之后,集成人员必须对这些修改进行集成和测试,当项目到达一个新的稳定的状态之后,集成人员还应当提升项目的基线以便开发人员统一在新的项目基线下继续开发。集成人员的主要工作包括:

1.         创建集成视图

2.         根据开发人员的修改创建新的基线

3.         集成和测试新的基线

4.         在新的基线到达一个稳定状态后将此基线提升为项目的标准基线,通知开发人员更新各自的开发流和开发视图,进入项目的下一个迭代

ClearCase的文档(参考“Workflows for Managing Projects with UCM”)中对集成人员的职责有不同的划分,主要的区别在于“为项目创建或者设定Component”被认为是项目集成人员的工作

4、 软件开发部运用ClearCase的可行性

部门项目管理需求

1.         能够使得团队在项目版本控制上摆脱拷贝的原始手段

2.         能够使得团队协作能力得到提高,取代原有的发送邮件等协作方式

3.         使得项目管理员能够对每个成员的工作更好的分配和跟踪

项目管理需求与ClearCase的功能比较

1.         ClearCase UCM模式下,项目中所有的资源都可以纳入到CC的版本控制中,并且能够通过CC了解其版本变更的所有历史。因此CC可以满足我们对项目管理的第一点需求;

2.         ClearCase软件的模式是典型的C/S模式,项目开发人员通过创建各自的开发流和开发视图来进行开发,这使得开发人员可以独立的并行的进行工作。同时开发人员通过Deliver各自的工作可以将其修改共享给其他开发人员,而其他开发人员只需要对他们的开发视图进行更新即可得到这些更新。因此CC可以满足第二点需求。

3.         CC能够对项目中的每一次变更都进行跟踪,并可以比较不同对象版本之间的差异,通过这些差异我们可以了解项目成员在某一时段内的工作成果。而每个开发人员各自的开发流完整的记录了所有的变更,也就是说记录了在这一项目中开发人员所做的所有工作。

使用ClearCase的障碍

ClearCase基本能够满足目前我们部门对项目管理的需求,但实际使用将可能遇到以下障碍:

1.         目前我们能够得到的ClearCase软件只能支持单人开发,其他解决办法个人觉得不太可行,这是部门使用CC的最大障碍;

2.         ClearCase安装、配置、使用相对较复杂,需要进行团队培训,否则很难正确的高效的运用CC进行项目管理。另外由于第一点障碍的存在,个人在对ClearCase的了解和学习过程遇到很多无法回避的问题,同时也使得个人对CC中的很多概念没有切实的体验,比如项目管理员、集成人员和开发人员在使用CC进行工作的直观体验;

3.         ClearCase目前没有中文版本,这可能初学者的使用带来一些困难

5、 项目管理软件简要比较

目前几款重要的项目管理软件除了Rational ClearCase还有Microsoft Visual SourcesafeCVSSVN等。以上几款软件中,CVSSVN在功能和使用上基本一致,也可以说SVN是从CVS发展而来的一个比CVS更新的版本,因此下面的比较CVSSVN将都以SVN来代表。下面就个人经验谈谈对几款软件的认识:

1.         从软件架构来看,CCSVN是典型的C/S模式,而VSS则不是。因此CCSVN都可以通过建立服务器来达到在局域网甚至internet进行项目管理的目的,而VSS只能在局域网中使用,并且VSS的数据库必须存放在一个共享的文件夹内,这给安全性带来隐患;

2.         ClearCase的权限管理集成域控制机制,这既可以说是CC的一个优点也可以认为是CC的一个不方便之处;

3.         并行开发模式。项目管理的模式有Copy-Modify-MergeLock-Modify-Unlock两种。VSS支持Lock-Modify-Unlock模式,但在此模式下不支持并行开发,目前部门使用VSS采用的是这种模式。而VSSCCSVN都支持Copy-Modify-Merge模式。在Copy-Modify-Merge模式下,开发人员的协作将变得更加简单,各自的工作将不会受到其他人员的影响,只有在提交(注:这里的提交对VSS来说是Check in操作,但对CC来说既包括Check in操作也包括Deliver操作,且主要指Deliver操作,因为Check outCheck inCC中主要发生在开发视图中,而开发视图一般不是并行的)修改的时候才可能需要处理版本上的冲突,而这种冲突可以很简单的通过好的文件结构来避免。比如Tom负责文件File1的更新,但File1依赖Kate负责的File2,由于File2的内部实现的复杂性,Tom不能直接使用File2进行测试File1的工作,那么Tom在开发的时候完全可以修改他的工作副本中的File2文件以保证File1的测试顺利进行,然后在他可以仅仅将File1的修改提交。CC有一个特别之处在于CC可以记录每个项目成员的所有工作,而VSSSVN只能跟踪每个文件的每一次更新是由谁完成的,但不能集中的反映项目成员的所有工作。

4.         与开发环境的集成。VSS与开发环境集成较好,但是VSS有个缺点是VSS会修改slnvsproj等文件来完成对项目文件的管理CC在可以通过ClearCase Explorer来工作,也能够与Visual Studio集成,但他在可视化有一点缺陷,不能直观的反映出文件夹及其内容的状态。SVN的客户端是一个Windows Explorer的外壳程序,通过右键菜单便可以方便的完成项目的管理。SVN需要在每个工作副本下的文件夹添加一些隐藏的配置文件,但SVN提供从受控项目中获得干净的所有相关资源的命令。另外SVN对其控制的文件使用一套特别的图标来标识文件的工作副本目前与版本库的状态差异,这个人觉得是一个重要的优点。

5.         性能和易用性。VSS因为没有服务端,它对版本库的操作完全是对任一个VSS软件自由的,因此其性能不是太好,在数据量不大的情况下,可以接受。另外VSS版本库容易损坏,比如机器死机或者断电都可能造成版本库的某个部分不可用。CC服务器采用多线程机制,性能较好,但其安装、配置、使用相对较复杂,需要进行团队培训。SVN的服务端配置有一定难度,但其客户端使用简单直观。SVN的性能也较好。

  评论这张
 
阅读(491)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017