長い間CruiseControlコミッターとハドソンを使用したことがない人として、私はかなり偏見がありますが、それに対する私の見解は：
Hudsonは（大部分はNice Webインターフェースから）立ち上げて実行するのがはるかに簡単で、非常に活発なプラグイン開発コミュニティがあります。
CruiseControlは、多くの サードパーティのもの からサポートされており、プラグインの事前構成やinclude.projectsなどのxml構成を使用して、プロジェクトで構成情報をバージョニングできる巧妙なトリックを行う利点があります。
いくつかのビルドのみを使用する場合は、ハドソンが明確な勝者だと思います。 xmlを気にせずに多くの機能を使用する場合は、CruiseControlのxml構成トリックが本当の強みになると思います。
私の最後のプロジェクトは、CruiseControlから始めました。揺れた。その後、ハドソンに移動しました。ハドソンについて好きなこと：
上流および下流プロジェクト。したがって、データアクセスコードへのコミットは、最終的にプレゼンテーションレイヤーのビルドもトリガーします。
既存のプロジェクトを新しいプロジェクトの開始点として簡単に使用できます。したがって、開発ブランチを作成する習慣がある場合は、これらが継続的に統合されていることを確認するのは簡単です。
違いの1つは、ハドソンが単一の天才知性の産物であるということです。川口浩介。そのため、一貫性があり、一貫性があり、堅実です。マイナス面は、進捗率に何らかの制限がある可能性があります。しかし、コースケは信じられないほど多作なので、私はそれについてあまり心配しません。また、拡張可能であるため、Kohsukeに時間がない（または望まない）ものがある場合は、おそらく自分でそれを行うことができます。
Cruise ControlとHudsonの両方を調べましたが、セットアップと構成がはるかに簡単だったため、Hudsonを選択しました。 Hudsonは最近、定期的なリリースとプラグインによる拡張性で非常に広く使用されているようです。私はそれを強くお勧めします。
私の意見では、ハドソンはよりユーザーフレンドリーな選択肢です。 （もちろんwebappの初期インストールとは別に）Webインターフェースを介して完全にセットアップおよび保守できます。
CruiseControlについてこれが言える唯一の方法は、組み込みのXMLファイルエディターを数えることです。
それでも、両方を使用したので、自動ビルドを使用しないよりも、どちらかを優先します。
クルーズコントロールを試してみました...良い...しかし、ドキュメントは断片化されていますダッシュボードはわかりにくいです。ウィジェットの作成も混乱を招きます。ハドソンを試したことはありません。週末に試着します。
私は最近、Subversionを利用してBorland BDS 2006プロジェクトを構築するためにJenkinsをセットアップしましたが、非常に満足しています。私はまだCruiseControlを使用したことがないので、比較することはできません。詳細については、私のブログ投稿をご覧ください。