ClearCaseとの継続的な統合は可能ですか？

Question

私たちはJenkinsサーバーで夜間のビルドを実行しており、ClearCaseをソース管理管理として使用しています。

ClearCaseがファイル中心であるため、ファイルチェックインが1つずつ動作します。 SVNやGit（リポジトリ中心）とは異なり、開発者による変更はコミットされませんatomically。

これは、開発者がもうアクティブでなく、ClearCaseサーバーが午前1時にロックを持つため、夜間は問題ありません。したがって

10:55 AM - Developer1 checks in element1 
10:55 AM - Developer1 checks in element2 
10:56 AM - Developer1 checks in element3 
11:00 AM - ### Jenkins runs BUILD #1 ### <-- succeeds 
11:29 AM - Developer2 checks in element1 
11:29 AM - Developer2 checks in element2 
11:30 AM - ### Jenkins runs BUILD #2 ### <-- fails (element3 is missing) 
11:29 AM - Developer2 checks in element3 

、ですが、リリースはを構築します（：

しかし、ここでは（のは、半時間ごとに実行するビルドとしましょう）、開発者はその日によってアクティブな懸念の原因となることができるものの一例ですClearCaseと検討する価値のある「ASAP Builds」または文字通り「継続的インテグレーション」）、あるいは夜間のビルドにいつまでも満足すると非難されていますか？

Answer 1

、あなたはgitの/ SVNに埋めることができ、そしてベースラインが作成されたときにのみ、オンデマンドでビルドをトリガーします。

その方法：

• 開発者のコ​​ントロールの継続的ビルドが適切であるが、ベースラインを追加する（および必要に応じて古いものをクリーニングします）。
• Jenkinsは、ベースラインを促進することができ、ビルドが成功したか失敗したかを簡単にトレースできます。
あなたもに使用する開発者のためのスクリプトを提供することができます

：

• チェックインの現在のすべてのチェックアウトファイル
• は自動的
ことでしょう

ベースラインを設定します現在のコードベースがいつコミット（およびテスト）されるのに十分安定しているかをユーザーが判断できるので、ユーザーが継続的な統合をトリガーするのを助けます。単にシフト手段（すべてのに上のファイルをシフトラベルをつけてください：ファイルがそのラベルを持つ以前のバージョンを持っている場合、ラベルは次のようになりますが、まだベースClearCaseとそのアイデアを使用することができます

---

開発者がちょうどチェックインした最新バージョンに移動しました）。

あなたのJenkins CCビューは、そのラベルを持つすべてのファイルを表示するように設定されています。つまり、ラベルが新しいバージョンに移動すると、Jenkinsによって行われたcleartool lshistoryが変更され、ビルドがトリガーされます。 （注：cannot yet do it for a pattern of label）

Answer 2

クリアケースプラグインがありますhttps://wiki.jenkins-ci.org/display/JENKINS/ClearCase+Pluginこれは実装が少し複雑ですが、最近の更新があります。一方

あなたはUCMを使用している場合、あなたも ClearCase UCM Pluginを考慮することができる How to bridge git to ClearCase?