CMI based UCM CCCQ and CCRTCintegration 2.docx
- 文档编号:3516038
- 上传时间:2022-11-23
- 格式:DOCX
- 页数:20
- 大小:1.78MB
CMI based UCM CCCQ and CCRTCintegration 2.docx
《CMI based UCM CCCQ and CCRTCintegration 2.docx》由会员分享,可在线阅读,更多相关《CMI based UCM CCCQ and CCRTCintegration 2.docx(20页珍藏版)》请在冰豆网上搜索。
CMIbasedUCMCCCQandCCRTCintegration2
Abstract:
ClearCase和其他产品的传统集成方法是当需要和一个产品集成就做一套针对性方案,和每个产品的集成配置操作复杂而不高效,源代码中涉及很多集成产品的逻辑,这样导致扩展性不好,源代码难以维护。
新的集成方案采用的是可插拔式,动态加载,通过统一的定制好的规则接口和新产品的通信,ClearCase的源代码无需任何改动,就可以方便快捷的和第三方产品集成,而且配置,使用都很简单,这种简易的集成特性,拓展了ClearCase在其他领域的应用。
本专题通过具体的例子详细介绍了如何通过使用CMI实现UCMClearCase与ClearQuest及RTC的集成,展现ClearCase在UCM下强大的集成功能和易用性。
背景介绍
此CMI系列前一篇文章介绍了BaseClearCase和CLM产品如RTC,CQ等的集成原理和使用,本文将介绍UCMClearCase和CLM其他产品的集成使用,读者可以对比和上篇Base的区别来参考如何通过CMI实现UCMClearCase的集成。
UCM:
UnifiedChangedManagement的缩写,统一变更管理模式,是IBMRational提出的用于管理软件开发过程(包括从需求到版本发布)中所有变更的“最佳实践”流程。
UCM通过抽象层次的提升简化了软件开发,从而使得软件开发团队从更高的层次根据活动(activity)来管理变更。
通过UCM,一个开发活动可以自动地同其变更集(封装了所有用于实现该活动的项目工件)相关联,这样避免了管理人员手动跟踪所有文件变更。
在介绍UCMClearCase的CMI集成功能之前,需要了解一下几个概念,这些会在后面的操作时经常提到
Activity:
Activity是ClearCaseUCM模式中的一个概念,通过变更集(ChangeSet)跟踪完成一项开发任务所引起的所有配置项的变更。
CheckOut、CheckIn、AddtoSourceControl等引起配置项发生变化的操作住UCM下必须关联到一个Activity。
Stream:
UCM的概念,项目开发的主干,类似BaseClearCase里的Branch概念。
有集成流和开发流两种,每个开发流都是集成流的一个分支,在开发流上完成工作后,再提交到集成流上,然后在集成流上做成Build。
Provider:
所要集成的产品如CLM里的RTC,CQ,这些Server本身提供OSLC功能的的集成接口,Provider不仅限于Rational自身产品还包括将能扩展集成的任何第三方产品,只要此Server提供OSLC接口功能和相应的Driver库。
此Driver库用来ClearCase集成时动态加载。
Task:
是Provider里的一条记录,主要针对RTC的一条工作项,包含TaskID和Task描述等,每个ClearCase元素的集成信息都关联到相应的Provider的一条Task,如果是CQ就是相应的一条Record,语义上和RTC的task类似,也有RecordID。
UCMClearCaseCMI原理及目前状态
ClearCaseUCM的集成在ClearCase以前的版本就有,ClearCaseUCM和ClearQuest的集成作为配置管理变更管理工具一直帮助客户实现整个软件周期的管理,当时由于Rational关于软件生命周期的管理的产品有限,ClearCase的集成主要针对ClearQuest单个产品解决方案,这就造成ClearCase的集成操作多针对ClearQuest一个产品的特性,源代码中很多针对ClearQuest定制的专有代码,随着Rational产品的丰富以及更新换代,ClearCase在面对新产品的集成无法继续为每个产品都提供一个集成方案,这样一个统一的集成方案的需求迫在眉睫,而CMI正是这个需求的产物,它提供了统一的集成接口,并动态加载需要集成产品的驱动库和实现OSLC数据访问功能的产品实现交互,OSLC是IBM产品都遵循的一个数据访问服务交互模式。
几乎所有产品都提供OSLC的访问和交互功能。
从此,ClearCase里的源代码将不会以后针对相应产品的功能的特殊描述,取而代之的是用户自己定义的产品Provider的名字,CMI后台通过客户指定的Provider的名字来动态加载相应的驱动库(由集成产品提供,接口一致),然后查找provider的配置地址来实现具体的集成操作。
新的集成方案CMI定义了统一的,标准化的接口,需要集成的产品只需要实现Interface,双方通过此接口定义的一些方法来通信,此类似于JDBC/ODBCdriver解决和产品数据库连接和操作的思想。
使用体验上实现了pluggable的使用CMI的功能,CMI的具体命令和ClearCase自身的command集成在一起,并添加了关于CMI的相关参数和命令,这对于已经数量掌握ClearCase的管理员来说很容易理解和上手。
如果用户启用了CMI的功能意味着在常规的checkin/out等操作后还要执行把新版本信息关联到Provider的具体Task里,这里添加了事务管理概念,使得本身的checkin/out操作和集成操作在一个事务管理内,任何一个操作失败将导致整个事务操作失败,保证ClearCase和Provider端的一致。
通过在version,branch,stream上添加一个简单属性TaskID@ProviderName,“@”符号区分符后面是所集成的server名字,前面是这个server的相关记录的ID.整个集成过程都围绕着这个接口信息通过OSLC的方式以URL访问CLM应用来调用和跟踪变更。
可以同时和多个产品Server实现集成,一次checkin/out.多个产品同时记录相关联的涉及的代码变更。
新的CMI集成方案和传统的方法具备了共同的特性:
1.通过会话session机制实现批处理和server交互。
2.通过队列机制处理交互阻塞。
3.保持ClearCase管理的代码状态和server状态一致,有一定的容错性。
4.自动关联和自动解关联。
在ClearCaseV7.1.2.9及V8.0.0.6以上版本中,ClearCase实现了CMI与CLM的集成,如下所示:
UCMClearCase/ClearQuest/RTC通过CMI进行集成;(本文内容)
BASEClearCase/ClearQuest/RTC通过CMI进行集成;
RTC-CTE通过CMI方式进行集成;
RTC-VisualStudio通过CMI方式进行集成;
CCRCCLI(rcleartool)基于CMI的增强。
本篇文章通过具体例子,详细介绍如何使用CMI来实现UCMClearCase与ClearQuest以及RTC的集成。
准备工作
在进行例子之前,我们需要安装一些Rational的软件,包括ClearCase8.0.0.8以上版本,同时需要已经配置好的ClearQuest服务器以及RTC服务器,并创建样例数据。
在我们引入的例子中,我们使用了的版本如下:
RationalClearCase以及ClearQuest8.0.0.9版本
RationalJazzTeamServerVersion:
4.0.4M1版本
使用UCMClearCase通过CMI和ClearQuest集成
步骤一:
准备将要集成的UCMClearCase,CQprovider集成的环境
UCMClearCase的CMI集成和BaseClearCase的集成都需要通过OSLC,所以我们得首先使Schema支持OSLC,如图1-4所示:
图1.在ClearQuestDesigner中为当前CQSchema添加OSLC补丁包
PIC1.jpg
图2.选择当前最高版本OSLC补丁包
PIC2.jpg
图3.指定需要支持OSLC的RecordTypes
PIC3.jpg
图4.更新ClearQuest用户DB
PIC4.jpg
以上操作是为了在要集成的ProviderServer准备环境和数据,并让Provider提供OSLC访问接口。
此过程和BaseClearCase的环境准备类似。
步骤二:
准备UCMCMI的集成环境
本文演示的集成操作都是在RHEL6.3i386GNU/Linux平台上进行。
命令行方式是ClearCase管理员经常使用、最快捷的clearcase操作方式。
本文通过命令行的方式来详细介绍基于CMI的UCMClearCase和ClearQuest集成的具体操作,帮助用户更深入的理解ClearCase的CMI功能。
首先,我们需要通过ClearCase命令创建基于UCM的Project,为CC和CQServer集成做好准备。
图5.创建存储view和vob的storage库
PIC5.jpg
图6.创建ucmproject需要的VOB
PIC6.jpg
图7.创建所需component,并在projectVOB上创建集成/开发流及相应视图
如图所示,下面开始创建ucmproject、PVOB和elementVOB所需要的component,并在这个PVOB上创建集成流、集成视图,开发流以及开发视图。
PIC7.jpg
以上步骤是用UCM来做版本管理的必备程序。
UCM的概念和原理这里不再详细介绍,简单的说它是在base基础上形成的统一变更管理模式,UCM通过抽象层次的提升简化了软件开发,从而使得软件开发团队从更高的层次根据活动(activity)来管理变更(changeset)。
步骤三ClearCaseCMI相关的配置工作。
图8.VOB添加CMI所必须的属性
PIC8.jpg
图9.为VOB创建连接CQ的Provider
从V8.0.0.7起,ClearCase本地客户端(cleartool和nativeGUIs)支持基于CMI的UCM-CQ集成。
ClearCase与ClearQuest通过OSLC接口进行交互
以下范例完成在projectvob里创需要集成的ProviderServer。
下面语句在所要集成的VOB里创建一个名字为CQPROV的ProviderServer,并自动关联到VOB属性里。
Pic9
mkcmprovider相关参数介绍如下。
-vob:
指定需要使用CMI与CLM集成的vob;
-type:
当前所创建的CMIProvider类型,由于是与CQ集成,因此值为”cmcq”;
-ver:
CMI功能版本号,值为”v1_0”;
-desc:
当前CMIProvider描述信息;
-connection:
providerserver提供的OSLCURL地址,格式为:
baseurl:
http:
//ip/cqweb/oslc;
CQPROV是我们所创建的CMIProvider的名字
这里的-ver和-type是特定的provider类型,CMI需要这两个信息加载相应的驱动库,如果填写错误将导致无法找到相应的provider错误。
CMI会验证connection地址的正确性,如果未通过验证,将报URI地址无法访问错误。
图10.在Vob里的Stream上引用在Vob里定义的Provider信息
此操作必须在Vob里创建完Provider信息后,否则就会报找不到相应Provider的错误。
如果是采用UCM集成,需要在stream引用此provider,并将provider与stream上的activity做关联。
如果是采用base集成,需要在branch上引用此provider,并将provider与branch里的具体element版本做关联。
UCMClearCase与ClearQuest集成独特之处在于:
在activity上关联集成的provider,如CQ,RTC的server信息后,在这个activity下所有的version更改信息就会传到ServerProvider端。
UCM的集成粒度比Base要大,不需在单个文件上做关联,当然这种关联也是通过从配置信息里自动获取并打上标签属性,无需手动参与。
PIC10.jpg
Activityformat属性定义了activity格式。
因此在mkact命令创建activity时将默认使用此格式,自动创建activity名字,除非你重新指定所要创建的activity名字。
enable属性用于确定是否启用ClearCase与provider的集成,如果不想再和这个provider集成,可以设置属性enable为false。
validate属性用于确定这个provider的某个task必须和ClearCase的activity有关联,就是ClearCasevob里的activity必须关联到此provider的某个task。
后面的文章会详细讲解这里的逻辑规则以及错误处理。
最后通过lsprovider命令检查在vob和stream上的provider配置是否正确,在配置之前也可以先lsprovider查看是否有人已经配置,以免重复配置。
如果需要更改这个provider的相关配置,可以在创建命令行里添加“-replace”参数。
具体的,请运行cleartoolmkcmprovider–help获得相关命令使用帮助。
步骤四:
对应之前创建的Provider,创建所需的CQ认证属性
通过”cmiregisteradd-cq-nameCQPROV-userdbCQWAN-dbsetCQWAN-usernameadmin”命令创建对应之前创建的Provider所需的CQ认证属性,从而记录连接CQ所需要的登陆信息;添加完成后,可以通过“cmiregisterlist”命令来进行查看。
图11.创建并记录链接CQ的登录信息
PIC11.jpg
步骤五:
通过Cleartoolmkact创建activity,并为当前的ClearCase操作与ClearQuestrecord相关联,如下图12,13所示。
Activity是ClearCaseUCM模式中的一个概念,通过变更集(ChangeSet)跟踪完成一项开发任务所引起的所有配置项的变更。
在UCM模式下,所有的CheckOut、CheckIn、AddtoSourceControl等引起配置项发生变化的操作必须关联到一个Activity。
图12.创建Activity,通过命令将CCactivity与CQRecord做关联
用户在任何时候要向控制vob添加资源或修改已经处于vob控制之下的资源,都必须将操作与某个UCM活动相关联。
我们在stream上创建activity的同时,可以创建此activity关联的provider的taskid。
实例:
cleartoolmkact-nc-tasksCQWAN00000001@CQPROVlzhao_act2
mkact相关参数介绍如下:
-tasks参数是专门为做UCM集成加入的。
CQWAN00000001就是providerCQPROV的一个defectid。
此创建过程会验证ClearQuestserverprovider和defectid信息的正确性,如果不存在会报错,但是activity仍然能创建成功,就是没有关联到相关ClearQuestserver。
Lzhao_act2是将创建的活动名称。
如果不指定名称,根据前面的设置,系统将自动创建格式为ACT_%task-id_%stream-name的活动。
然后可以用cleartoollsact-lSample_act去确认此activity已关联到相应的provider和taskid,如下图书所示:
PIC12.jpg
图13.为activity设定默认关联provider的task信息
通过cleartoolsettask命令可设定默认关联的Provider的Task信息,这样你在每次checkin/out操作时,CMI会根据此设定的信息来和Provider集成。
如下图所示:
PIC13.jpg
RedHat系统里Root目录下的.ccas_current_tasks记录了默认的集成信息,你可以手动在这文件里添加,也可以用cleartoolsettask命令来添加。
如上图实例:
.ccase_current_tasks中包含两个view和provider的集成信息,一个是rtcprovider,另一个是CQPROV。
cmi_view是在BaseVob里创建的view,int_view实在UCMVob里创建的view。
settask–none用于清空默认的task集成信息。
图14.为activity设定关联provider的多个task
当然如果愿意,我们可以将activity与provider的更多task相关联。
此activity的changeset会自动更新到所有相关联的server上。
在ServerProvider端,一条记录可以关联到几个activity或变更的版本。
UCMCMI集成为cleartoolsetact增加了一个-tasks的参数,允许用户为将要工作的activity指定若干具体的task。
如
cleartoolsetact-tasksCQWAN00000001@CQPROV,CQWAN00000002@CQPROV
另外,UCMCMI集成增加了如下命令:
cleartoolchact-tasks{-add_tasktask-selector[,...]|
-remove_tasktask-selector[,...]|-rmall}
activity-selector[,...]
允许用户同时增加或删除此activity关联的tasks。
可以同时用-remove_tasktask1,-add_tasktask2来替换activity的task,也可以-task-rmall来删除所有activity关联的provider信息。
如下图所示
PIC14.jpg
此activityact2已经有了关联的taskCQWAN00000001@CQPROV,运行命令cleartoolchact-tasks-add_taskCQWAN00000002@CQPROV-remove_taskCQWAN00000001@CQPROVact2.
在CQProvider端,CQWAN00000001关联的activity被删除了,同时此activity关联到了CQWAN00000002@CQPROV上。
此例也可以看到基于UCM和基于Base的ClearCase集成的不同之处,基于Base的CMI集成关联的是改动的源代码版本信息,而基于UCM的CMI集成关联的是activity信息。
图15.在CQWeb中查看指定Record对应的CC中变更信息
当这个activity创建成功,并且关联到CQProviderCQPROV的记录CQWAN00000001,就可以在CQ页面上看到所关联的变更集包含了刚才我们创建的activity,如图所示:
PIC15.jpg
步骤六:
删除UCMClearCase与ClearQuest的集成信息,如下图16,17所示。
图16.删除所创建的activity,此操作将删除关联到provider的CQRecorder
删除activity的操作将同时会把所有关联到此activity的providerServer的集成信息一同删掉,此操作逻辑包含了操作
cleartoolchact–rmall
如下图所示:
当操作rmact时,所关联的providerserver响应时间会稍有等待,原因是CMI后台会联系ProviderServer提交解关联(disassociation)操作。
完成后再执行删除ClearCase端的activity的操作,最后返回删除成功信息。
PIC16.jpg
图17.删除在vob和stream上配置的provider信息
如果需要删除此provider的相关配置,可以通过rmprovider命令去删除。
删除时,该命令通知并需要你确认:
你对此vob上provider的更改会导致和stream(UCM)或branch(Base)的配置不一致,需要同时手动更改在stream或branch上关于此provider的配置。
就是说你在上级vob上更改的集成provider信息不会自动更新到相关的stream(UCM)或branch(Base)上,需要手动去更新,并且相关type和version的值必须准确。
ClearCase后台程序将根据你输入的值去需找相应的驱动库,从而为后面的删除操作做准备。
通过rmprovider去删除在vob,stream,brtype上配置的provider信息。
如下图所示:
Usage:
rmprovider{-vobvob-selector|-replicareplica-selector|
-brtypebrtype-selector|-streamstream-selector}
provider_name
PIC17.jpg
使用UCMClearCase通过CMI和RTC集成(TBD)
由于RTC本身已经支持OSLC,因此当我们需要实现BaseClearCase与RTC集成时,只需要配置特定的针对RTC的CMIProvider即可。
从V8.0.0.7起,ClearCase本地客户端(cleartool和nativeGUIs)支持基于CMI的UCMClearCase与RTC集成。
在配置集成前,ClearCase管理员需要配置集成相关的VOBs和UCMstreams。
步骤如下所示:
步骤一:
安装CLMjazz平台并在RTC创建样例项目。
图18.RTC样例工作项
PIC18.jpg
我们创建了几个样例工作项主要有ID和Summary信息。
步骤二:
通过“Cleartoolmkattype”命令,为指定的VOB添加CMI所必需的attrType属性CC_CMI_PROVIDERS。
如图19所示:
图19.为VOB添加CMI所必须的属性
PIC19.jpg
步骤三:
通过“Cleartoolmkcmprovider-vob”命令创建对应于RTC的Provider,该Provider用于保存当前所需要集成的RTC提供服务的OSLC地址信息baseUrl;同时通过“Cleartoolmkcmprovider-stream”命令为指定的VOB及其stream添加CMI进行查询时所需的queryUri相对地址,如图20,21所示:
图20.为VOB创建连接RTC的Provider
以下范例完成在projectvob里创需要集成的ProviderServer。
下面语句在所要集成的VOB里创建一个名字为RTCPROVU的ProviderServer,并自动关联到VOB属性里。
Pic20.jpg
mkcmprovider相关参数介绍如下。
-vob:
指定需要
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- CMI based UCM CCCQ and CCRTCintegration
![提示](https://static.bdocx.com/images/bang_tan.gif)