HudsonとCruiseControl for Javaプロジェクトの違いは何ですか？

StackOverflow https://stackoverflow.com/questions/604385

質問

タイトルはそれを要約していると思います。 SvnのJavaプロジェクトの継続的な統合ビルドに、どちらが優れているのかを知りたいだけです。

役に立ちましたか？

解決

長い間CruiseControlコミッターであり、 ハドソンを使用したことがない人として、私はかなり偏見がありますが、私の考えは次のとおりです。

Hudsonは（大部分は素晴らしいWebインターフェースから）立ち上げて実行するのがずっと簡単で、非常に活発なプラグイン開発コミュニティがあります。

CruiseControlは、多くのサードパーティのものからサポートされており、プラグインの事前設定やinclude.projectsなどのxml設定を使用して、プロジェクトの設定情報をバージョン管理できるようにする、すてきなトリックを実行します。

もしあなたがいくつかのビルドしか持たないなら、ハドソンが明確な勝者だと思います。あなたがたくさん持っているつもりであり、xmlを気にしないのであれば、CruiseControlのxml設定のトリックは本当の強みになると思います。

他のヒント

に同意しますこの回答が、いくつかのポイントを追加したい。

要するに、 Hudson （更新： Jenkins ）は現在、より良い選択です。何よりも重要なのは、CruiseControlのXML構成ファイル（バージョン管理に使用していたもの）の編集と比較して、HudsonのWeb UIでジョブ（CCボキャブラリの「プロジェクト」）の作成と構成が非常に高速追跡しやすくするためです）。後者は特に難しくありません-単に遅くて退屈です。

CruiseControlは優れていますが、Dan Dyerの適切な名前のブログ投稿 Hudsonをまだ使用していないのはなぜですか 、最初に苦しんでいます。 （もしあなたがイギリスのように、もしあなたが後から産業革命に参入するなら、他の人が新しい技術で追い越し始めたときです。）

CruiseControlを頻繁に使用し、徐々にハドソンに切り替え、最終的に排他的に使用しました。さらに、さらに：Hudsonジョブのセットアップと管理が非常に便利であるため、以前よりも多くの他のことにCIサーバーを使用し始めました。 （現在、Hudsonには40以上のジョブがあります：安定ブランチと開発ブランチの通常のビルド＆テストジョブ、リリースに関連するジョブ（インストーラーのビルドなど）、コードベースに対していくつかの（実験的）メトリックを実行するジョブ、実行するジョブ（遅い）特定のデータベースバージョンに対するUIまたは統合テストなど）

この経験から、複雑なビルドを含む多くのビルドがある場合でも、CCのように、基本的に何でもを実行するためにHudsonがかなり安全な選択であると主張します。任意のAntまたはMavenターゲット、Unixシェルスクリプト、またはWindows .batスクリプトを希望する順序で実行するようにジョブを設定するだけです。

サードパーティのもの（ここでジェフリー・フレドリックが言及）-それは良い点ですが、私の印象では、ハドソンはすぐに追いついており、すでに非常に多くの利用可能なプラグイン。

私にとって、CruiseControlで見逃している2つのことは次のとおりです。

  1. 壊れたビルドに関する警告メールは、ハドソンのメールよりも有益でした。ほとんどの場合、根本原因はCCの適切にフォーマットされたHTMLメール自体から明らかでしたが、Hudsonでは通常、Hudson Web UIへのリンクをたどり、詳細を確認するには少しクリックする必要があります。
  2. CruiseControlダッシュボードは、すぐに使用できる＆quot; < a href = "http://www.agileadvice.com/archives/2005/05/information_rad.html" rel = "nofollow noreferrer">情報ラジエーター＆quot; （公共のモニターに表示されるか、壁に投影されるため、すべてのプロジェクトのステータスを常にすばやく確認できます）。 Hudsonのフロントページでは、ジョブの行をすべて緑/赤にするためにGreasemonkeyのトリックが必要でした。

軽微な免責事項：私は昨年ほどCCプロジェクトを厳密にフォローしていません。 （ただし、クイックルックからは、劇的な変化はありません。）

注（2011-02-03）：ハドソンはでした

最後のプロジェクトは、CruiseControlから始めました。揺れた。その後、ハドソンに移動しました。ハドソンについて好きなこと：

  • 上流および下流プロジェクト。したがって、データアクセスコードへのコミットは、最終的にプレゼンテーションレイヤーのビルドもトリガーします。

  • 既存のプロジェクトを新しいプロジェクトの開始点として簡単に使用できます。開発ブランチを作成する習慣がある場合は、これらのプロジェクトが継続的に統合されていることを確認するのは簡単です。

1つの違いは、ハドソンは天才的な知性と川口康介の産物です。そのため、一貫性があり、一貫性があり、堅実です。マイナス面は、進捗率に何らかの制限がある可能性があります。しかし、コースケは信じられないほど多作なので、私はそれについてあまり心配しません。また、拡張可能であるため、Kohsukeに時間がない（または望まない）ものがある場合は、おそらく自分で行うことができます。

Cruise ControlとHudsonの両方を調べましたが、セットアップと構成がはるかに簡単だったため、Hudsonを選択しました。 Hudsonは最近、定期的なリリースとプラグインによる拡張性で非常に広く使用されているようです。強くお勧めします。

ハドソンは、私の意見ではよりユーザーフレンドリーな代替手段です。 （もちろんwebappの初期インストールとは別に）Webインターフェースを介して完全にセットアップおよび保守できます。

CruiseControlについてこれが言える唯一の方法は、組み込みのXMLファイルエディターを数えることです。

それでも、両方を使用しましたが、自動ビルドを持たないよりも、どちらかを好むでしょう。

クルーズコントロールを試みました...それは良いことですが、ドキュメントは断片化されています。ダッシュボードはわかりにくいです。ウィジェットの作成も混乱を招きます。ハドソンを試したことはありません。週末に試着します。
ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top