ClearCase Trigger指南(8)-可以设置Trigger的ClearCase操作

可以设置TriggerClearCase 操作

声明:在本文中描述的Trigger在实际应用中需要做修改,如果直接应用可能会产生不明后果,本文作者对此概不负责。

首先我们来看一下应用UCM模式的TriggerUCMRational 已经提供一些基本的流程定制,可以简化我们创建分支、版本归并的许多操作,但是每个项目都是独一无二的,对于复杂的项目,UCM不能完全满足需要。所有UCM类型的操作基本对应同样Cleartool子命令,其中Deliver类、Rebase类及mkbl_complete操作是特例,这些操作不对应具体的cleartool子命令。针对UCM模式有以下几类ClearCase操作:

<!--[if !supportLists]--&gt1. <!--[endif]--&gtDeliver:将源流的修改提交到目标流;创建Trigger可以针对deliver_startdeliver_canceldeliver_complete这三个操作;cleartool deliver子命令会引起这几个操作;Deliver包括Deliver from StreamDeliver Baseline两种。在创建完Trigger后,需要将Trigger关联到目标流上,Trigger才能起作用。在创建针对Deliver操作的Trigger时只能设置StreamProject进行约束。

<!--[if !supportLists]--&gt2. <!--[endif]--&gtRebase:从源流获取最新的修改;其中包括rebase_startrebase_cancelrebase_complete这三个操作。与Deliver操作类似,在创建完Trigger后,需要将Trigger关联到目标流上,Trigger才能起作用。在创建针对Rebase操作的Trigger时只能设置StreamProject进行约束。

<!--[if !supportLists]--&gt3. <!--[endif]--&gtActivity:其中包括mkactivitychactivityrmactivitysetactivity这四个操作。其中针对mkactivityTrigger需要关联到要创建活动的流,其他三个操作的Trigger需要关联到要操作的活动。在创建针对Activity操作的Trigger时只能设置StreamProject进行约束。

<!--[if !supportLists]--&gt4. <!--[endif]--&gtStream:其中包括mkstreamchstreamrmstream这三个操作。其中针对mkstream Trigger需要被关联到要创建流的project,其他两个操作的Trigger需要关联到被操作的流。同时,在创建针对mkstream操作的Trigger只能设置Project进行约束,而对其他两个操作可以设置Streamproject约束条件。

<!--[if !supportLists]--&gt5. <!--[endif]--&gtBaseline:其中包括mkblmkbl_completechblrmbl这四个操作。mkbl_complete操作是一个特例,从cleartool mkbl子命令来看,针对的是Component,而mkbl_complete是对一个Stream上所有的Component打上baseline的操作,可以理解为在图形界面下,针对一个Stream执行Make Baselines。所以针对mkbl_complete Trigger必须关联到要执行Make BaselinesStream上,其他三个操作都要被关联到与Baseline有关的Component上;针对mkblmkbl_complete操作,可以设置StreamComponentProject约束条件,针对另两个操作只可以设置ComponentProject 约束条件。另外针对mkbl,如果在环境变更中CLEARCASE-PROJECTCLEARCSE_STREAM都没有被定义,则针对Component执行Import Label时也会触发Trigger

<!--[if !supportLists]--&gt6. <!--[endif]--&gtProject:其中包括mkprojectchprojectrmproject这三个操作。其中针对mkproject操作的trigger需要关联到PVOB,并且不能设置约束条件,另两个条件则需要关联到被操作的Project上,并可以针对Project设置约束条件。

<!--[if !supportLists]--&gt7. <!--[endif]--&gtComponent:其中包括mkcomprmcomp这两个操作。针对这两个操作的trigger需要被关联到PVOB,并且不能设置约束条件。

<!--[if !supportLists]--&gt8. <!--[endif]--&gt其他:其中包括mkfolderchfolderrmfolder这三个操作。针对这些操作的的Trigger需要被关联要操作的Folder,并且可以设置project约束条件。

在前面根据需要定制Trigger一节,描述了我对Deliver操作的理解,这里我们仔细看一下,针对Deliver的操作我们可以定制哪些Trigger,需要注意这些Trigger都比较简单,是针对某一项非常明确的需求,在具体应用时要加以组合成为一个Trigger

<!--[if !supportLists]--&gt1. <!--[endif]--&gtdeliver_startStream Policy中有一些设置可以理解为已设置好的Triggerdeliver_start这个操作的事前触发的Trigger在检查完ProjectStreamPolicy之后才会被触发,所以没有必要在这里设置Trigger检查源流是否有未Check in的配置项、是否执行了Rebase操作等,这些可以通过设置StreamPolicy来解决;针对deliver_start,可以设置以下Trigger

<!--[if !supportLists]--&gta) <!--[endif]--&gt事前触发(preop)Trigger,检查是否有Deliver的权限:Cleartool mktrtype –ucmobject c "Only Cuibz could execute deliver opeartion" -element -preop deliver_start -nusers cuibz -execunix "Perl -e "exit -1;"" -execwin "ccperl -e "exit (-1);"" deliver_check;之后我们可以将这个Trigger关联到相应的流上,需要注意的是DeliverRebase类型操作的Trigger要关联到要DeliverRebaseStream上,即目标流,否则不会起作用;cleartool mktrigger deliver_check stream:test_Int@Test_PVOB,这里你可以根据实际情况修改stream。如果目标流上只允许有deliver权限的人员进行Deliver操作,则可以不设置这个trigger,而是简单的锁定目标流,同时将有权限的操作人员加入Excluded中即可。

<!--[if !supportLists]--&gtb) <!--[endif]--&gt事前触发的trigger,锁定目标流,这样可以避免针对同一个配置项进行多个Deliver同时操作导致的MergeCheck outReservedUnreserved的问题(对一个配置项只能有一个Reserved 类型check out操作,其他都为Unreserved操作,在Reserved类型check out没有check in之前,其他Unreserved类型的check out操作不能check in);需要注意,如果认定了这个Trigger,则要有针对deliver_canceldeliver_complete的事后触发的trigger,来对目标流及源流进行解锁。具体的Trigger如下:cleartool mktrtype –ucmobject –preop deliver_start –exec “cleartool lock –nusers %CLEARCASE_USER% stream:%CLEARCASE_STREAM%” -comment “Lock source stream except operater” deliver_lock_targetstream。其中lock命令的参数中-nusers %CLEARCASE_USER%的目的是在锁定目标Stream后,可以让deliver这个操作的发起用户不受影响,否则会无法执行deliver操作;%CLEARCASE_STREAM%是目标Stream,但是前面一定要加上stream:这个前缀,否则锁定时cleartool lock这个命令会无法识别,导致deliver操作被拒绝。

<!--[if !supportLists]--&gtc) <!--[endif]--&gt事前触发的trigger,锁定源流,这样可以避免准备提交时,有用户check in不准备提交的版本;具体Trigger如下:cleartool mktrtype –ucmobject –preop deliver_start –exec “cleartool lock –nusers %CLEARCASE_USER% stream:%CLEARCASE_SRC_STREAM%” -comment “Lock target stream except operater” deliver_lock_sourcestream%CLEARCASE_SRC_STREAM%是源Stream。你可以将这这个trigger与前一个trigger结合起来,同时锁定目标流与源流,具体trigger如下:cleartool mktrtype –ucmobject –preop deliver_start –exec “cleartool lock –nusers %CLEARCASE_USER% stream:%CLEARCASE_STREAM% stream:%CLEARCASE_SRC_STREAM%” -comment “Lock target and source stream except operater” deliver_lock_stream

<!--[if !supportLists]--&gtd) <!--[endif]--&gt事前触发的trigger,通过脚本对源流进行构建,以验证提交的源码的完整性,如果构建失败,则可以自动回滚deliver操作,并给出提示;这个trigger如果和下一个结合在一起可以支持在目标流上的Daliy Build工作。

<!--[if !supportLists]--&gte) <!--[endif]--&gt事后触发的trigger,对目标流进行构建,如果构建失败,则执行自动执行deliver –cancel回滚deliver操作;一般情况下建议和上一个trigger合并为一个trigger,先检测在源流修改是否可构建,再检测目标流上配置项经过merge后,是否可构建,这样可以支持在目标流上的Daliy Build工作。

<!--[if !supportLists]--&gtf) <!--[endif]--&gt事后触发的trigger,对锁定的源流进行解锁。 Trigger如下:cleartool mktrtype -ucmobject –postop deliver_start –exec “cleartool unlock stream:%CLEARCASE_SRC_STREAM%” -comment “Unlock source stream” deliver_unlock_source_stream

<!--[if !supportLists]--&gtg) <!--[endif]--&gt事前触发的trigger,将deliver的发起人、源流、目标流、活动等信息发送邮件到相关人处。可以参见IBM Rational ClearCase随机帮助文档cc_proj.pdf

<!--[if !supportLists]--&gth) <!--[endif]--&gt如果应用脚本等,还可以建议设置其他的trigger,如锁定源流上要提交的活动,或检查目标流上要进行归并的配置项是否处于check out状态等。

<!--[if !supportLists]--&gti) <!--[endif]--&gt检查目标流是是否有正在执行的Deliver操作。保证目标流上的Deliver是唯一的,这个脚 本在 IBM Rational ClearCase的随机帮助文档cc_proj.pdf中有,章节为Working in UCM -> Using Trigger to Enforce Development Policies -> Enforce Serial Deliver Operations,读者可以自行查看。

<!--[if !supportLists]--&gt2. <!--[endif]--&gtdeliver_cancel:如果没有执行deliver_complete,则回滚deliver操作,针对这个clearcase操作,可以设置以下trigger

<!--[if !supportLists]--&gta) <!--[endif]--&gt事前触发的trigger,检查权限,确保只有deliver操作发起者与配置管理人员才能进行回滚deliver操作,这样可以避免以下这种情况:一个deliver在进行中,其他人员由于尝试进行其他deliver导致回滚原deliver问题。

<!--[if !supportLists]--&gtb) <!--[endif]--&gt事前触发的trigger,将deliver -cancel的消息发送到相关人员处。

<!--[if !supportLists]--&gtc) <!--[endif]--&gt事后触发的trigger,对目标流、源流、活动等进行解锁,如果在deliver_start中设置了trigger对目标流、源流、活动等锁定,则回滚时一定要进行解锁。

<!--[if !supportLists]--&gtd) <!--[endif]--&gt事后触发的Trigger:与事前触发的保证 Deliver操作唯一性的Trigger对应,同样参见IBM Rational CleaseCase的随机文档cc_proj.pdf

<!--[if !supportLists]--&gt3. <!--[endif]--&gtDeliver_complete:将目标流上check out的配置项check in,并打上隐藏的delivered基线,针对这个clearcase操作,可以设置以下trigger

<!--[if !supportLists]--&gta) <!--[endif]--&gt事前触发的trigger,检查权限,确保只有deliver操作发起者与配置管理人员才能进行执行deliver -complete操作。

<!--[if !supportLists]--&gtb) <!--[endif]--&gt事后触发的trigger,对应deliver_start相应的trigger,如果在deliver_starttrigger中锁定了目标流、源流或活动,则在deliver_complete后进行解锁。

<!--[if !supportLists]--&gtc) <!--[endif]--&gt事前触发的trigger,对目标流进行构建,如果构建失败,则提示进行回滚,一般情况下建议如果在deliver_start中设置事后触发的trigger检查对目标流进行构建检查,则不必在deliver_complete设置此trigger

<!--[if !supportLists]--&gtd) <!--[endif]--&gt事后触发的trigger,将目标流打上baseline

<!--[if !supportLists]--&gte) <!--[endif]--&gt事后触发的trigger,发起对目标流上所有静态视 图的update操作。

<!--[if !supportLists]--&gtf) <!--[endif]--&gt事后触发的trigger,发送邮件通知相关人员,deliver已经完成,构建工程师可以进行构建及版本发布,测试人员可以开始测试工作。

<!--[if !supportLists]--&gtg) <!--[endif]--&gt事后触发的trigger,自动对各个相关的流执行rebase,这个trigger需要注意,一般情况下只rebase推荐基线,刚deliver的不一定是稳定的基线,所以不建议使用该trigger

针对其他UCM类型操作的Trigger可以参考IBM Rational ClearCase随机帮助文档cc_proj.pdf

接着我们来看一下针对配置项的ClearCase操作有哪些可以定义Trigger;需要注意,和针对UCM对象的ClearCase操作不同,针对配置项的ClearCase操作并不等同于cleartool的子命令。针对配置项的ClearCasse操作有以下几类:

<!--[if !supportLists]--&gt1. <!--[endif]--&gtModify_ELEM:对配置项的修改,包括以下ClearCase操作

<!--[if !supportLists]--&gta) <!--[endif]--&gtcheckoutCheck out命令一定会导致这个操作,clearimportfindmergemkelemmkbranch relocate命令可能会发起checkout操作。针对checkout操作,我们可以设置Trigger,发送通知有checkout操作进行,尤其是针对clearimportfindmergemkelemmkbranch relocate操作,因为这些命令如果导致checkout操作,大多数情况下是增加配置项或更改配置项的目录等,这种情况需要通知相关人员。也可以用Trigger进行权限控制等。如果是多个开发人员在一个开发流上进行开发,也可以设置一个事后触发的Trigger,将所有Reserved类型的Checkout改为Unreserved类型,以防止针对同一配置项多人Check out后,如果Reserved Check out没有执行Check in操作,其他Check out都不能执行check in操作;针对checkoutTrigger除了设置配置项类型与分支类型的约束条件。

<!--[if !supportLists]--&gtb) <!--[endif]--&gtchevent:为配置项关联的某个event修改注释,一般情况下只有chevent命令可以导致这个操作;针对这个操作,设置事前触发的Trigger只允许配置管理员执行可以防止对注释的错误修改。

<!--[if !supportLists]--&gtc) <!--[endif]--&gtreserve:将unserved类型的checkout操作改为reserved类型的checkout操作,一般情况下可以设置一个事前触发的Trigger,防止开发人员任意修改操作导致其他开发人员必须等待,不能执行check in操作的问题。

<!--[if !supportLists]--&gtd) <!--[endif]--&gtunreserve:将reserved类型的check out操作改为Unreserved类型的Check out操作;可以设置一个事前触发的Trigger,防止其他人修改check out类型,限制任意的check out操作,这个TriggerreserveTrigger是对立的;也可以设置一个事后触发的Trigger,邮件通知原check out操作人员,你的check out操作类型被修改了,其他人可以不等原操作者Check in就执行Check in操作了。

<!--[if !supportLists]--&gte) <!--[endif]--&gtuncheckout:回滚Check out操作;可以设置事前触发的Trigger,检查权限,只允许Check out操作人与配置管理人员执行该操作。

<!--[if !supportLists]--&gt2. <!--[endif]--&gtMODIFY_DATA:包括以下ClearCase操作:

<!--[if !supportLists]--&gta) <!--[endif]--&gtCheck in操作:check inmkelemmkbranch一定会导致这个操作,clearimportrelocate可能会导致这个操作。可以设置事前触发的Trigger,检查权限;也可以设置事后触发的Trigger,更新静态视图,可以应用脚本检查注释是否符合要求等。

<!--[if !supportLists]--&gtb) <!--[endif]--&gtchtype:修改配置项的类型及各个Type,只有chtype会导致这个操作;可以设置事前触发的Trigger,检查权限。

<!--[if !supportLists]--&gtc) <!--[endif]--&gtlnname:将配置项链接到某个目录配置项,lnln –smkelemmkdirmv一定会导致这个操作,relocate可能会导致这个操作;可以设置事前触发的trigger检查权限。

<!--[if !supportLists]--&gtd) <!--[endif]--&gtlock:这里的lock只是针对配置项的lock,而不包括对TypeUCM Object;可以设置事前触发的trigger检查权限。

<!--[if !supportLists]--&gte) <!--[endif]--&gtmkbranch:产生新的分支;mkbrachmkelem一定会导致这个操作,checkoutclearimportrelocate可能会导致这个操作;可以设置事前触发的trigger检查权限。

<!--[if !supportLists]--&gtf) <!--[endif]--&gtmkelem:新建配置英;mkelemmkdir一定会导致这个操作,clearimportrelocate可能会导致这个操作;可以设置事前触发的trigger检查权限。

<!--[if !supportLists]--&gtg) <!--[endif]--&gtmkslink:在目录配置项下建立另一个配置项的Symbolic Linkln –s一定会导致这个操作,可以设置事前触发的trigger检查权限。可以设置事前触发的trigger检查权限。

<!--[if !supportLists]--&gth) <!--[endif]--&gtprotect:修改配置项的OwnerGroup及权限;只有protect会导致这个操作;可以设置事前触发的trigger检查权限。

<!--[if !supportLists]--&gti) <!--[endif]--&gtrmbranch:删除分支;只有rmbranch会导致这个操作;可以设置事前触发的trigger检查权限。

<!--[if !supportLists]--&gtj) <!--[endif]--&gtrmelem:完全的删除配置项;rmelem一定会导致这个操作,relocate可能会导致这个操作发生;再这里再一次介绍我认为最重要的Trigger,强烈建议所有的VOB 要建立这个Trigger,禁止配置管理人员以外人员删除配置项:Cleartool mktrtype -c "Only Cuibz could execute rmelem" -element –all -preop rmelem -nusers cuibz -execunix "Perl -e "exit -1;"" -execwin "ccperl -e "exit (-1);"" rmelem_check

<!--[if !supportLists]--&gtk) <!--[endif]--&gtrmname:从一个目录配置项内移走一个配置项;rmnamermelemmv一定会导致这个操作;可以设置事前触发的trigger检查权限。

<!--[if !supportLists]--&gtl) <!--[endif]--&gtrmver:删除配置项的某一个版本;rmver一定会导致这个操作,注意:checkvob –fix命令也可能会导致这个操作;同rmelem一样,建议一定要建立禁止配置管理人员以外人员删除版本的事前触发的triggerCleartool mktrtype -c "Only SCM could execute rmelem" -element –all -preop rmver -nusers cuibz -execunix "Perl -e "exit -1;"" -execwin "ccperl -e "exit (-1);"" rmver_check

<!--[if !supportLists]--&gtm) <!--[endif]--&gtunlock:对配置项进行解锁;可以设置事前触发的trigger检查权限。

<!--[if !supportLists]--&gt3. <!--[endif]--&gtMODIFY_MD,有以下ClearCase操作:

<!--[if !supportLists]--&gta) <!--[endif]--&gtchmaster:主要是针对Multisite ClearCase的,修改配置项的Mastership

<!--[if !supportLists]--&gtb) <!--[endif]--&gtmkattr:将定义好的attribute关联到配置项;mkattr一定会导致这个操作,clearimportmkhlinkrelocate可能会导致这个操作发生;

<!--[if !supportLists]--&gtc) <!--[endif]--&gtmkhlink:将定义好的hyperlink关联到配置项;mkhlink一定会导致这个操作,clearimportfindmergemergerelocate可能会导致这个操作发生;

<!--[if !supportLists]--&gtd) <!--[endif]--&gtmklable:将定义好的label关联到配置项的某个版本;mklabel一定会导致这个操作,clearimportrelocate可能会导致这个操作发生;

<!--[if !supportLists]--&gte) <!--[endif]--&gtmktrigger;将定义好的Trigger关联到配置项;mktrigger一定会导致这个操作,relocate可能会导致这个操作发生;

<!--[if !supportLists]--&gtf) <!--[endif]--&gtrmattr:取消配置项上关联的某个attribute;只有rmattr会导致这个操作;

<!--[if !supportLists]--&gtg) <!--[endif]--&gtrmhlink:取消配置项上关联的某个hyperlinkrmhlinkrmmerge一定会导致这个操作的发生;

<!--[if !supportLists]--&gth) <!--[endif]--&gtrmlabel:取消配置项某个版本关联的label;只有rmlabel会导致这个操作的发生;

<!--[if !supportLists]--&gti) <!--[endif]--&gtrmtrigger:取消配置项关联的某个Trigger;只有rmtrigger会导致这个操作的发生;

针对以上这些操作,可以设置Trigger检查权限。

最后是针对Type的操作,前文提到针对Type操作的Trigger设置不需要应用mktrigger,下面我们来看一下有哪些针对Type的操作可以设置Trigger

<!--[if !supportLists]--&gt1. <!--[endif]--&gtchevent:修改Type对象事件的注释;

<!--[if !supportLists]--&gt2. <!--[endif]--&gtchmaster:主要是针对Multisite ClearCase的,修改Type对象的Mastership

<!--[if !supportLists]--&gt3. <!--[endif]--&gtlock:锁定type对象;

<!--[if !supportLists]--&gt4.

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10446695/viewspace-925918/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/10446695/viewspace-925918/

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
©️2021 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值