现在的位置: 首页 > 综合 > 正文

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

2013年09月15日 ⁄ 综合 ⁄ 共 7627字 ⁄ 字号 评论关闭
 本文欢迎任何非商业用途转载,请注明作者,出处

可以设置TriggerClearCase 操作

 

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

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

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

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

3.        Activity:其中包括mkactivitychactivityrmactivitysetactivity这四个操作。其中针对mkactivityTrigger需要关联到要创建活动的流,其他三个操作的Trigger需要关联到要操作的活动。在创建针对Activity操作的Trigger时只能设置StreamProject进行约束。

4.        Stream:其中包括mkstreamchstreamrmstream这三个操作。其中针对mkstream Trigger需要被关联到要创建流的project,其他两个操作的Trigger需要关联到被操作的流。同时,在创建针对mkstream操作的Trigger只能设置Project进行约束,而对其他两个操作可以设置Streamproject约束条件。

5.        Baseline:其中包括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

6.        Project:其中包括mkprojectchprojectrmproject这三个操作。其中针对mkproject操作的trigger需要关联到PVOB,并且不能设置约束条件,另两个条件则需要关联到被操作的Project上,并可以针对Project设置约束条件。

7.        Component:其中包括mkcomprmcomp这两个操作。针对这两个操作的trigger需要被关联到PVOB,并且不能设置约束条件。

8.        其他:其中包括mkfolderchfolderrmfolder这三个操作。针对这些操作的的Trigger需要被关联要操作的Folder,并且可以设置project约束条件。

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

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

a)        事前触发(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中即可。

b)        事前触发的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操作被拒绝。

c)        事前触发的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

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

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

f)         事后触发的trigger,对锁定的源流进行解锁。  Trigger如下:cleartool mktrtype -ucmobject –postop deliver_start –exec “cleartool unlock stream:%CLEARCASE_SRC_STREAM%” -comment “Unlock source stream” deliver_unlock_source_stream

g)        事前触发的trigger,将deliver的发起人、源流、目标流、活动等信息发送邮件到相关人处。可以参见IBM Rational ClearCase随机帮助文档cc_proj.pdf

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

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

2.        deliver_cancel:如果没有执行deliver_complete,则回滚deliver操作,针对这个clearcase操作,可以设置以下trigger

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

b)        事前触发的trigger,将deliver -cancel的消息发送到相关人员处。

c)        事后触发的trigger,对目标流、源流、活动等进行解锁,如果在deliver_start中设置了trigger对目标流、源流、活动等锁定,则回滚时一定要进行解锁。

d)        事后触发的Trigger:与事前触发的保证 Deliver操作唯一性的Trigger对应,同样参见IBM Rational CleaseCase的随机文档cc_proj.pdf

3.        Deliver_complete:将目标流上check out的配置项check in,并打上隐藏的delivered基线,针对这个clearcase操作,可以设置以下trigger

a)        事前触发的trigger,检查权限,确保只有deliver操作发起者与配置管理人员才能进行执行deliver -complete操作。

b)        事后触发的trigger,对应deliver_start相应的trigger,如果在deliver_starttrigger中锁定了目标流、源流或活动,则在deliver_complete后进行解锁。

c)        事前触发的trigger,对目标流进行构建,如果构建失败,则提示进行回滚,一般情况下建议如果在deliver_start中设置事后触发的trigger检查对目标流进行构建检查,则不必在deliver_complete设置此trigger

d)        事后触发的trigger,将目标流打上baseline

e)        事后触发的trigger,发起对目标流上所有静态视 图的update操作。

f)         事后触发的trigger,发送邮件通知相关人员,deliver已经完成,构建工程师可以进行构建及版本发布,测试人员可以开始测试工作。

g)        事后触发的trigger,自动对各个相关的流执行rebase,这个trigger需要注意,一般情况下只rebase推荐基线,刚deliver的不一定是稳定的基线,所以不建议使用该trigger

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

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

1.        Modify_ELEM:对配置项的修改,包括以下ClearCase操作

a)        checkoutCheck 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除了设置配置项类型与分支类型的约束条件。

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

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

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

e)        uncheckout:回滚Check out操作;可以设置事前触发的Trigger,检查权限,只允许Check out操作人与配置管理人员执行该操作。

2.        MODIFY_DATA:包括以下ClearCase操作:

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

b)        chtype:修改配置项的类型及各个Type,只有chtype会导致这个操作;可以设置事前触发的Trigger,检查权限。

c)        lnname:将配置项链接到某个目录配置项,lnln –smkelemmkdirmv一定会导致这个操作,relocate可能会导致这个操作;可以设置事前触发的trigger检查权限。

d)        lock:这里的lock

抱歉!评论已关闭.