クリアケースのUCMトリガーはマルチサイト環境で面倒です

Question

継続的な統合を実現するために、私はClearcaseトリガーを書くことを考えました。

私は事後トリガー[統合ストリームに配信後]がわかりました。

トリガーの実装に関して私のアーキテクトからアドバイスを求めるだけです。

彼はマルチサイト環境で面倒ですトリガーとして使用しないように私に言った。

この神話は本当ですか？トリガーのためにビルドをもっと迷惑にさせた問題に直面しましたか？

マルチサイト環境でトリガーを使用するのは安全ですか？

Answer 1

あなたの建築家がその事実アウトポンれ、this technoteに参照されている可能性がありますデザインすることで

を、トリガータイプは、各VOBにローカルに作成する必要があります。

トリガタイプは、他のメタデータタイプ（ラベル、属性、ブランチ、要素、ハイパーリンク）と異なり、ハイパーリンクを正しくトラバースできないため、管理VOB内のグローバルリソースとして作成できません。これは、管理VOBがクライアントVOBに接続する方法です。

あなたは試してみて、トリガーをコピーすることができます。

cptype（コピータイプ）コマンドは、既存のタイプのオブジェクトのコピーである新しいタイプのオブジェクトを作成します。既存のオブジェクトと新しいオブジェクトは、同じVOB内にあっても、異なるVOB内にあってもかまいません。別のVOBでコピーを作成している場合に限り、コピーの元の名前と同じ名前を付けることができます。

しかし：

二つのオブジェクト、オリジナルとコピーこのコマンドを実行した後、任意の接続を保持しません。
これらは同じプロパティを持つ2つのオブジェクトに過ぎず、おそらく同じ名前にすぎません。 cleartool mktrtype -replaceを使用するなど、トリガに変更があった場合は、トリガの各コピーに対して手動で変更する必要があります。または、-replaceスイッチを使用して再度コピーを実行する必要があります。詳細については、cptype reference pageを参照してください。

---

私は、トリガーを監視し、継続的な統合を報告する外部システムを使用することをお勧めします。

次のいずれかを実行できます

• ではなく、マルチサイトのワークフローのCCRCを使用して、ClearCaseのセットアップを簡素化します。より一般的に

• ：、記事「Continuous integration with IBM Rational ClearCase Remote Client」は（ジェンキンスまたはハドソンやチームシティーは、この場合にも同様に優れているあなたはCruiseControlのを使用する必要はありません）することができ、その場合には
  CIツール（再び：CruiseControl：JenkinsまたはHudsonまたはTeamCity）に、CIツールが定期的に更新された特定のビューを監視し、変更を検出してビルドをトリガすることができます。 「Realizing continuous integration」を参照してください。