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

ClearCase Trigger指南(6)-根据需要定制trigger

2013年09月15日 ⁄ 综合 ⁄ 共 2658字 ⁄ 字号 评论关闭

本文欢迎任何非商业用途转载,请注明作者,出处。

根据需要定制Trigger

优化ClearCase,支持配置管理流程

配置管理是一个系统,包括三部分:工具、人员、配置管理的流程与纪律,工具的目的是在流程与纪律的约束下,配合人员、简化人员的工作;经常有这样的情况发生,我们可以找到许多ClearCase的脚本和Trigger,但是拿来用时并不尽如人意,常有一些意想不到的问题发生,带来许多麻烦。这就应了一句话:“江南为桔,江北为枳”,我们需要根据自身的实际情况来修改与定制脚本与Trigger

第一步要确定配置管理的流程制度,这取决于我们要做一个什么样的软件,是一个项目,还是半定制的产品、或是产品线或其他类型,这些是配置管理系统的根基,配置管理系统的任务就是服务好这个目标;根据目标与组织结构确定开发的方式,不同的目标与组织结构要使用不同的开发方式,如果只是一个简单的项目,则没有必须进行并行开发,如果是产品线,则并行开发是不可避免的;目标、组织结构与开发方式共同决定了配置管理的流程与制度。

在流程与制度确定后,我们要看一下Rational ClearCaseUCM是否满足流程与制度的需要。在这里需要注意的是,工具只是配合流程与制度的,而不能决定流程与制度,一些配置管理的新手在这一阶段常常不由自主的根据工具来决定流程与制度。如果我们使用UCM,这时要决定ProjectStream,再根据组织结构与任务安排确定每个ProjectStream上的项目的配置Policy;最后在流程与制度中寻找当前UCM所不支持的部分,看一下是否需要应用Trigger或脚本来实现。

在定制流程时,如果要应用Trigger,则要对Trigger所针对的ClearCase 操作有深入的了解,这样才能写出有效的Trigger。例如:如果要针对deliver_start这个创建Trigger,则要了解deliver这个clearcase操作具体步骤,以下是我对deliver这个clearcase操作的理解:

1.        检查当前流上是否有一个DeliverRebase正在进行中,如果有,则提示当前正有一个DeliverRebase过程在运行中。

2.        检查目标流的Deliver policy,如果不符合Stream policy,则拒绝执行deliver并给出提示。

3.        检查源流的Deliver Policy,如果不符合Stream policy,则拒绝执行deliver并给出提示。

4.        选择要提交的活动,检查活动的依赖关系。

5.        确定将要进行操作的目标流的视图。

6.        检查确定的目标流操作视图上目前是否有Check out的配置项,如果有提示,在要提交的目标流的操作视图有Check out操作,退出。

7.        开始执行Deliver操作,这里是deliver_start的开始;创建Deliver活动,将要操作的目标流视图的当前活动设置为该Deliver活动,一般情况下,在Deliver没有完成前在图形界面下与命令行中不能修改该视图的当前活动,但是可以通过一些特殊方法进行修改。在这一步开始后,如果以后的任务失败,则要执行deliver –cancel才能删除Deliver活动,并对Check out的配置项进行Undo Check out操作。

8.        获取每个要提交的Activity的变更集。

9.        对所有需要在目标流上进行操作的配置项执行Check out操作,如果发现当前有配置项已经被Check out,记录错误并继续执行,在所有的Check out操作执行完毕后,给出在Deliver目标流操作视图上无法执行Check out的配置项列表并中止Deliver活动。注:在第6步检查的只是目标视图上是否有Check out,可能在其他视图上有Check out操作,执行Deliver时,要求配置项的Check out类型为Reserved类型,如果配置项已经在其他视图上进行了Check out操作,则不能进行Reserved类型Check out操作,无法保证在Deliver结束可以执行Check in操作,所以不能继续进行Deliver的归并。

10.    将要提交的配置项与目标流上已经Check out的配置项进行归并,根据设置进行自动归并或人工归并,如果自动归并失败,进行人工归并,如果某一配置项归并没 有完成,记录错误并继续执行,在所有的归并执行完毕后,给出归并失败的列表并中止Deliver活动。

11.    如果没有设置-force或是在图形界面下,归并完成后,提示用户Deliver操作归并完成。在此步还可以对Deliver操作进行回滚,到达第12步后,则不能进行回滚操作。

12.    在本步执行之前都可以执行deliver_cancel操作;本步活动是deliver_complete的开始;对所有Deliver操作的Check out的配置项进行Check in,在提交的源流打上一个隐藏的Delivered Label,同时结束对目标流操作视图当前活动的锁定,Deliver操作至此全部结束。

以上步骤是我对Deliver操作的理解,不是Rational ClearCase给出的指南,由于没有足够信息,所以可能和实际情况有一定偏差。从以上步骤可以看到,在前6步进行过检查的,不必设置deliver_startPreop类型的 Trigger进行重复检查。

再次强调,不要完全依赖配置管理工具来做事情,有些情况下用纪律来约束。例如:要求不能在集成流上进行Check out操作,则不必设置Trigger,通知所有人员严禁在集成流上进行Check out操作,在集成流上所有的操作都有记录,如果有人进行了操作,按纪律处理即可。同时,可以不利用trigger的,尽量不用trigger,例如derliver的问题,如果目标流上只允许进行具有deliver权限的人员进行deliver操作,则不必设置trigger,简单的对流进行锁定即可,同时在exclude中加入允许操作的人员即可。

为了方便定制流程,Rational ClearCase提供了一系列的Trigger环境变量,例如:CLEARCASE_PN是当前element类型Trigger的操作对象。可以利用cleartool man mktrtype获取有哪些环境变量及这些环境变量的具体含义与使用方法。

 

抱歉!评论已关闭.