78

私は現在、主に大規模な C++ プロジェクトの継続的統合に jenkins/hudson を使用しています。トランクとブランチごとに個別のプロジェクトがあります。また、Java コードに関連するプロジェクトがいくつかありますが、それらのセットアップは現時点ではかなり基本的なものです (ただし、後でさらに多くのことを行う可能性があります)。C++ プロジェクトは次のことを行います。

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

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

私たちは (当時) Hudson を使い始めました。これは、Java 関係者が使用していたものであり、夜間のビルドが必要だったからです。それ以来、私たちはさらに多くを追加し、さらに追加し続けています。いくつかの点でハドソンは素晴らしいですが、確かに理想的ではありません。

私は他のソリューションを見てきましたが、代わりになる可能性があると思われる唯一のソリューションはbuildbotです。この状況では buildbot の方が適しているでしょうか? すでに Hudson を使用しているため、投資する価値はありますか? なんで？

編集: Hudson/Jenkins が理想的であるとは思えない理由を誰かが尋ねました。簡単な答えは、すべてを改善できるということです。Jenkins が私のユースケースに最適な現在のソリューションなのか、それとも新しい要件が発生したとしても長期的に維持しやすい何か (buildbot?) があるのか​​ どうか疑問に思っています。

4

5 に答える 5

44

どちらもオープン ソース プロジェクトですが、buildbot コードを「拡張」するために変更する必要はありません。実際には、独自のパッケージを構成にインポートするのは非常に簡単で、ほとんどの機能を独自の追加でサブクラス化できます。例: 独自のコンパイルまたはテスト コード、次のステップに渡される出力/エラーの解析、アラート メールの独自の書式設定など、多くの可能性があります。

一般的に、buildbot は最も「汎用的な」自動ビルド ツールであると言えます。ただし、Jenkins はテストの実行に最も関連している可能性があります。特に、buildbot が「すぐに」実行しないことを、適切な方法 (結果、詳細、グラフなど) で解析して表示する場合に最適です。私は実際に両方を使用して、よりセクシーなテスト結果ページを作成することを考えています.. :-)

また、経験則として、新しいツールの構成を作成することは難しくありません。何を行うか (構成、ビルド、テスト) の仕様が、あるツールから別のツールに切り替えるのが難しすぎる場合、それは (悪い) 兆候です。十分な構成スクリプトがソースに移動されていないことに注意してください。Buildbot (または Jenkins) は単純なコマンドのみを呼び出す必要があります。テストを実行するのが簡単であれば、開発者もそれを実行し、これにより成功率が向上します。一方、継続的インテグレーション システムのみがテストを実行する場合は、新しいコードの失敗を修正するためにテストを実行することになり、結果が失われます。その非回帰値、ちょうど私の 0.02€ :-)

それが役立つことを願っています。

于 2011-05-06T10:14:56.030 に答える
6

「結果の統合」もjenkins/hudsonにあり、ビルド製品を「別の場所にコピー」することなく比較的簡単にキャプチャできます。

この例では、Java コードのカバレッジ レポートと単体テスト メトリック、および javadoc がすべて統合されています。私たちの C++ コードでは、プラグインが少し不足していますが、ほとんどのプラグインを入手できます。

0.7 より前から buildbot を実行しており、現在は 0.8 を実行していますが、buildbot 0.8 は長期間にわたって Windows スレーブを忘れており、サポートがかなり貧弱であったため、切り替える本当の理由が見られるようになりました。

于 2011-07-20T13:53:27.927 に答える
1

buildbot と成果物について -- コメントを作成するのに十分なユーザー スコアがありません -- 組み込みのファイル/ディレクトリ アップロード アクションを使用して、buildbot 2.x シリーズから成果物を非常に簡単に取得できます。ただし、ファイルを移動することはめったにありません。通常、最良の結果を得るために、ワーカーから直接デプロイを行うトリガーされたビルドステップを作成します。例: クラウド ストレージ、コンテナー、サードパーティ (Steam アップロード) などへのプッシュ。

このようにして、アップロードに関するメトリックを取得し、条件付きでより適切に制御できます (または、ワーカー マシン間でアーティファクトを組み合わせて一致させることもできます)。

于 2019-03-29T22:52:45.057 に答える