buildbotとhudson / jenkinsのC ++継続的統合
現在、主に大規模なC++プロジェクトの継続的な統合にjenkins/hudsonを使用しています。トランクとすべてのブランチに個別のプロジェクトがあります。また、Javaコードに関連するいくつかのプロジェクトがありますが、それらのセットアップは今のところかなり基本的です（ただし、後ほど行う場合があります）。C++プロジェクトは次のことを行います。
- 再構成、クリーンビルド、フレッシュチェックアウトのいずれを使用するかを選択できるオプションを使用してすべてをビルドします。
- オプションですべてのテストをビルドして実行します
- オプションでValgrindのmemcheckを使用してすべてのテストを実行します
- Cppcheckを実行します
- Doxygenドキュメントを生成します
- レポートの発行：単体テスト、valgrind、cppcheck、コンパイラー警告、SLOC、オープンタスク、コードカバレッジ（gcov、gcovr、coberturaプラグインを使用）
- コードを夜間またはオンデマンドでテスト環境とパッケージリポジトリに展開します
自動ビルドの場合はすべて構成可能で、オンデマンドビルドの場合はオプションです。その下には、これらの多くを制御するbashスクリプトがあります。これは、カスタムmakeとともにautomakeとautoconfを使用するビルドシステムにさらに依存します。
Hudsonを（当時）使用し始めたのは、Java guysが使用していたものであり、ナイトリービルドが必要だったためです。それ以来、さらに多くを追加し、さらに追加し続けています。ハドソンは素晴らしい方法もありますが、理想的ではありません。
私は他のソリューションを見てきましたが、代わりになりそうなのはbuildbotだけです。 buildbotはこの状況に適していますか？すでにハドソンを使用しているので、投資する価値はありますか？どうして？
[〜＃〜] edit [〜＃〜]：ハドソン/ジェンキンスが理想的とは思えない理由を誰かが尋ねました。簡単な答えは、すべてを改善できるということです。 Jenkinsが私のユースケースの現在の最善のソリューションであるのか、新しい要件が発生しても長期的に維持しやすいもの（buildbot？）があるのではないかと思っています。
どちらもオープンソースプロジェクトですが、buildbotコードを「拡張」するために変更する必要はありません。実際には、独自の追加機能を使用してほとんどの機能をサブクラス化できる構成で独自のパッケージをインポートするのは非常に簡単です。例：独自のコンパイルまたはテストコード、次のステップに渡される出力/エラーの解析、アラートメールの独自のフォーマットなど、多くの可能性があります。
一般的に、buildbotは最も「汎用的な」自動ビルドツールであると言えます。ただし、Jenkinsはテストの実行、特にニースの方法（結果、詳細、グラフ、クリック数回）で結果を解析して表示するのに最も適している可能性があります。私は実際に両方を使用してテスト結果ページをよりセクシーにすることを考えています.. :-)
また、経験則として、新しいツールの構成を作成することは難しくないはずです：実行する（構成、ビルド、テスト）の仕様が1つのツールから別のツールに切り替えるのが難しい場合、それは（悪い）サインです十分な構成スクリプトがソースに移動されていないこと。 Buildbot（またはJenkins）は、単純なコマンドのみを呼び出す必要があります。テストを実行するのが簡単な場合、開発者も同様に実行し、これにより成功率が向上します。一方、継続的インテグレーションシステムのみがテストを実行する場合は、新しいコードの失敗を修正するために実行します。その非回帰値、ちょうど私の0.02€:-)
それが役立つことを願っています。
「結果統合」もjenkins/hudsonにあり、ビルド製品を「他の場所にコピー」することなく比較的簡単にキャプチャできます。
この例では、カバレッジレポートと単体テストメトリクス、およびJavaコードのjavadocがすべて統合されています。C++コードの場合、プラグインは少し不足していますが、ほとんどを取得できます。
buildbot 0.8はWindowsのスレーブを長期間忘れており、サポートがかなり貧弱だったため、0.7より前からbuildbotを実行し、現在0.8を実行していますが、実際に切り替える理由はありません。
Jenkins/Hudson/BuildBot以外にも、他にも多くのソリューションがあります。
- JetbrainsによるTeamCity
- アトラシアンの竹
- Thoughtworksで行く
- クルーズコントロール
- OpenMakeマイスター
実際に実行しているエージェント（別名ノード）がそれらのタスクをサポートしている限り、実行していることに関する詳細はそれほど重要ではありません。
CIサーバーの美しさは、ビルドが変更されて新しいビルド（およびテスト）がトリガーされ、アーティファクトが公開され、テスト結果が公開されることに気づいています。
前述のようなCIツールを比較するときは、インターフェースの使いやすさ、分岐の容易さ（および自動マージなどの機能）、通知（XMPP/Jabberなど）、または情報ラジエーター（フックなど）のような機能を検討してください常にステータスを表示するモニターを設定します）。製品サポートも考慮する必要があります。Jenkinsのサポートは、質問があるときにコミュニティの質問に誰が回答しているかだけで十分です。
私の個人的なお気に入りはBambooですが、ライセンス料が付属しています。
私は、Buildbotを評価しているJenkinsの長年のユーザーであり、Buildbotをマルチモジュールソリューションに使用することを検討している人々にいくつかのアイテムを提供したいと思います。
*）Buildbotには、各ビルドに関連するファイルartifactsのすぐに使える概念はありません。私が見る限り、UIにはなく、組み込みの「ステップ」モジュールにもありません：
http://docs.buildbot.net/current/manual/configuration/buildsteps.html
...そしてサードパーティのプラグインが表示されません：
https://github.com/buildbot/buildbot/wiki/PluginList#steps
Buildbotは、特定のビルドからすべてのコンソール出力を収集しますが、重大なことに、それに関連するfilesを収集することはできません。
*）アーティファクトがサポートされていないため、複数のモジュールを単一のインストーラーにまとめる「コレクター」プロジェクトを作成するのは簡単ではありません。 Jenkinsには、ビルドを他のモジュールからのビルドでパラメーター化できる優れた機能があります（パラメータータイプはrunです）。
*）モジュール間の依存関係を確立することは、Buildbotではより複雑です。 3つのバイナリが依存するライブラリがあり、ライブラリが変更されるたびにそれらのバイナリを再構築するとします。JenkinsにはtriggersがありますUIに組み込まれています。 Buildbotでトリガーを実行する場合は、schedulers.Dependentを使用してスクリプトを作成する必要があり、Schedulers UIで多くのアイテムの輻輳が発生します。
*）Buildbotで作業しているときは、ほとんどすべての構成がコードのmaster.cfgで行われているようです。これはすごいイライラします。
*）Buildbotは、workerサーバーに加えてmasterの作成を強制します。これは、単一のビルドサーバーで十分な初心者やシステムにとっては面倒です。
Buildbotの評価を2日間行った後の私の印象は、主にartifactsがあるためJenkinsに固執するということです。 Buildbotは、より広範なカスタマイズのニーズがあり、それを行う時間がある場合にのみ使用するツールです。
ビルドボットとアーティファクトに関しては-コメントを作成するのに十分なユーザースコアがありません-ビルトインのファイル/ディレクトリアップロードアクションでビルドボット2.xシリーズからアーティファクトを簡単に取得できます。ただし、ファイルを移動することはほとんどありません。通常、最良の結果を得るためにワーカーから直接展開するトリガービルドステップを作成します。例：クラウドストレージ、コンテナ、サードパーティ（Steamアップロード）などにプッシュします。
このようにして、アップロードに関するメトリックを取得し、条件付きでそれらをより適切に制御できます（または、ワーカーマシン全体でアーティファクトを組み合わせて一致させることもできます）。