C++継続的統合のためのbuildbotとhudson/jenkinsの比較

質問

私は現在、ほとんどがC++の大規模なプロジェクトで継続的インテグレーションにjenkins/hudsonを使用しています。 私たちは、トランクとすべてのブランチのために別々のプロジェクトを持っています。 また、Javaコードのためのいくつかの関連するプロジェクトがありますが、それらのためのセットアップは、今はかなり基本的です（私たちは後でもっとやるかもしれませんが）。 C++プロジェクトは次のようなことを行っています。

• 再構成、クリーン インストール、またはフレッシュ チェックアウトを使用するかどうかのオプションを指定してすべてをビルドします。
• オプションですべてのテストをビルドして実行します。
• オプションで Valgrind の memcheck を使用してすべてのテストを実行します。
• cppcheck を実行します
• doxygenドキュメントの生成
• レポートの発行: ユニットテスト、valgrind、cppcheck、コンパイラの警告、SLOC、オープンタスク、コードカバレッジ (gcov、gcovr、および cobertura プラグインを使用)。
• テスト環境とパッケージリポジトリに毎晩またはオンデマンドでコードをデプロイします。

すべては自動ビルドのために設定可能であり、オンデマンドビルドのためにオプションです。 その下には、この多くを制御する bash スクリプトがあり、automake と autoconf をカスタム bash スクリプトと共に使用する私たちのビルド システムに大きく依存しています。

私たちが Hudson を使い始めたのは (当時)、Java の人たちが使っていたもので、私たちはただ毎晩のビルドを望んでいただけでした。 それ以来、私たちは多くのものを追加し、さらに追加を続けています。 ある意味では Hudson は素晴らしいものですが、確かに理想的ではありません。

他のソリューションも見てみましたが、代替になりそうなのは buildbot だけです。 この状況では、buildbot の方が良いのでしょうか? すでに Hudson を使用しているので、その投資に見合うだけの価値がありますか? なぜでしょうか？

EDIT : ある人が、なぜ私がHudson/Jenkinsを理想的だと思わないのか、と質問しました。 短い答えは、すべては改善することができるということです。 私は、Jenkinsが私のユースケースにとって現在の最良のソリューションなのか、それとも、新しい要件が出てきても長期的にメンテナンスしやすい何か良いもの(buildbot?)があるのか、単に疑問に思っています。

どのように解決するのですか？

どちらもオープン ソース プロジェクトですが、buildbot のコードを変更して "拡張する必要はありません。例：独自のコンパイルやテストコード、次のステップに渡す出力やエラーの解析、アラートメールの独自のフォーマットなど、多くの可能性があります。

一般的に、buildbot は最も汎用的な自動ビルドツールであると言えると思います。しかし、Jenkins はテストの実行に最も適しており、特に、buildbot ではできないことですが、結果を解析して美しい方法で表示します (結果、詳細、チャートなど、数回のクリックで表示されます)。私は実際に、よりセクシーなテスト結果ページを持つために、両方を使用することを考えています... :-)

また、経験則として、新しいツールの設定を作成するのは難しくないはずです。何をすべきか（設定、ビルド、テスト）の仕様が、あるツールから別のツールに切り替えるのが難しすぎる場合、それは設定スクリプトが十分にソースに移動されていない（悪い）兆候と言えます。Buildbot（またはJenkins）は、単純なコマンドを呼び出すだけでよいのです。テストを実行するのが簡単であれば、開発者もそれを行うようになり、成功率が向上します。一方、継続的インテグレーションシステムだけがテストを実行する場合、新しいコードの不具合を修正するためにその後に実行することになり、非進行性の価値が失われてしまうでしょう。）

お役に立てれば幸いです。