使用している継続的インテグレーションフレームワークとその理由 [閉まっている]

そこにはかなりの数の異なる継続的インテグレーション（CI）フレームワークがあり、どれが最も人気があるのだろうかと思っています。勤務している企業でどのフレームワークを使用しましたか？

あるCIフレームワークが他のCIフレームワークよりも人気がある理由はありますか？おそらく、それが提供する機能、それに統合されるもの、またはその単なるマーケティングによるものでしょうか？

rubyやpythonよりも、Javaと.netの世界では継続的インテグレーションがより多く使用されているようです。どうしてこれなの？

ハドソンまたはジェンキンス（後者は前者のフォークです）。理由：シンプル（インストールと使用が簡単）であり、柔軟性に優れています。プラグインは、考えられるほぼすべての機能を追加します。

数年前、私はdamagecontrolを使用しました。使い方も簡単でしたが、プラグインはありませんでした。しかし、著者は単純なソリューションをあきらめることを決定し、互いに通信する異なるサーバーで構成される新しいバージョンの開発を開始しました（一体何ですか？）。それはうまくいかず、プロジェクトはあきらめられました。私はしばらく捜索していましたが、cruisecontrol（複雑すぎる）も連続体も本当に私を捕らえませんでした。ハドソンまで、それは私にとって最初の瞬間からうまくいきました。

TeamCityは職場でも自宅でも使用しています。さまざまなビルドランナーを強力にサポートし、プラグインを介して拡張可能です。

構成のためにXMLの山を処理しないことは、私の本では大きなプラスであり、無料版は私の家のニーズに十分です。

TeamCityで発生した問題の1つは、.NETアセンブリを自動的にバージョン化することです。私は比較的複雑な回避策を設定する必要がありましたが、いったん適切な場所に置かれると、それは魅力のように機能しました。

個人的には、CruiseControlとCruiseControl.Netのみを使用したことがあります。この理由は経済学に関係しています。それらは適度に安定しており、一度セットアップすれば、それを維持するために必要なことはほとんどありません。通常、ユーザーコミュニティは非常に役立ち、ニーズに合わせて拡張できます。

とはいえ、私が知っている商用製品がいくつかあります（1つはJetBrains、もう1つはAtlassian）が、より良いセットアップエクスペリエンスと商用サポートを提供します。私はこれらの製品を試すつもりでしたが、実際にはまだチャンスがありませんでした。

CIツールは、インタープリター言語よりもコンパイルされた言語で重要な役割を果たしますが、それは、CIツールがインタープリター言語で無駄になっているということではありません。相互に依存する複数のプロジェクトがあり、変更が誤って依存関係を壊さないようにしたい場合-CIツールは非常に貴重です。

CIツールを使用すると、次の3つのクラスの問題を把握できます。

1. コンパイルエラー-クラスのシグネチャが依存関係を壊すような方法で変更された場合、成果物の放棄時間前にそれについて知ることが最善です。
2. 論理エラー-クラスの動作が依存関係を壊すように変化した場合、早期に知ることが最善です。これは、ある種の自動テスト、最も一般的な単体テストで確認する必要があります。
3. 受け入れテスト-最終製品で実行するテストの自動スイートがある場合、頻繁に実行するのが最善です。

解釈された言語はコンパイルされないため、キャッチするコンパイルエラーはありません。ただし、他の2つの問題はよくあることなので、CIツールはRuby / Python / Perl /などのプロジェクトに役立ちます。

論理エラーと受け入れテストポイントの両方のキーワードは、「自動化された」テストです。マシンで実行できる一連のテストがない場合、CIツールの大きな利点が失われています。時間の経過とともに自動化されたスイートを構築できるため、小規模で開始できます。

編集

多数のCIツールの機能比較については、この素敵なグラフを参照してください（その多くについては知りませんでした）。

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix

Team Foundation Serverの

堅牢なCI、Visual Studioとの緊密な統合、およびバージョン管理としてのGit。Hudsonのように、より柔軟なCIサーバーを見てきましたが、TFSが他の製品と緊密に統合されているため、経験が非常にシームレスになり、チームにとって理にかなっています。

CruiseControl.NETとHudsonの両方を使用します。私のビルドのいくつかはそれらの1つにあり、いくつかは他のビルドにあります。

どうして？ 私はビルドエンジニアではなく、ビルドエンジニアである彼がこのように設定しているからです！

ビルドのセットアップ方法やどちらの製品についての苦情についても問題はありません。私はあなたに物事がここにある方法を報告しています、実際のところ、あなたがこの視点に感謝することを願っています！

更新：私が答えを投稿してから、ハドソンは分岐してジェンキンスになりました。上記の推奨事項はJenkinsに適用されます。

パルス。基本的にはJust Worksで、忙しいビルドエンジニアにとっては大したことです。また、非常に優れた技術サポートも提供しています。私がとても気に入っている主な理由は、250以上のプロジェクトがあり、問題なくそれらを処理できるからです。ハドソンについても同じことは言えません。

私たちのチームは主にPython、C ++、Javaで作業しています。CIにはBuildbotを使用します。Tracと統合し、シンプルでわかりやすいように思われたので、最初に始めました。Pythonの世界で選択されているCIフレームワークだと思います。

ハドソン。それは時々少しバグがあり、より興味深いプラグインのいくつかは実際には動作しませんが、少し手に取ってそれはかなり使いやすいです。

代わりにおそらくPulseを使用しますが、複数のプラットフォームでビルドする必要がある場合は、$ 5kを超えます。

継続的な統合のためのCruiseControl.NET。CruiseControlで非常に多数のビルドプロジェクトをセットアップしたため、CCTrayデスクトップトレイアプリは、更新間隔が長い場合でも、非常に反応しません。

NAntのは、CruiseControlプロジェクトで実行されるビルドスクリプト用です。より複雑なビルドスクリプトの場合、カスタムC＃NAntタスクでNAntを拡張しました。これは非常に便利です。C＃でコードを記述する方が、NAntスクリプトを作成するよりもはるかに楽しいです。

私たちはMicrosoftのショップであり、Team Foundation Server環境を2010に移行すると、理論的にはMicrosoftのTeam Build 2010に移行します。

CIエンジンを実行しているかどうかに関係なく、コマンドラインからアプリケーションをビルドできることに注意してください。

つまり、CIエンジンはビルド呼び出しをシステム化するだけであり、特定のニーズに最適なエンジンを選択できます。

パーソンとしては、ハドソンが「いい」と感じるために主に好きですが、すべてが失敗した場合、あまり労力をかけずに別のものに切り替えることができることを知っています。もしそうなら、私はおそらく最初にアトラシアンによって作られたものを調査するでしょう、なぜなら私は「感じ」が好きだからですた他のプログラムのが。

互換性は、それらがどの言語で書かれているかを問わないことを意味することに注意してください。Webサーバーが必要です-入手してください。多くの同時スレッドが必要です-それらを使用してください。拡張性が必要です-瓶に入れてください。

「継続的インテグレーション」という用語を耳にする前に（これは2002年または2003年に遡ります）、cvsに接続し、メインプロジェクトと5つの小さなサブプロジェクトのクリーンコピーを取得して、すべてビルドしたナイトリービルドスクリプトを書きましたantを介したjarファイルは、tomcat antタスクを使用する2番目のantスクリプトを介してWARファイルをビルドおよび再デプロイしました。

午後7時にcronを介して実行され、多数の出力ファイルが添付された電子メールを送信しました。プロジェクトの7か月全体で使用し、次の20か月のメンテナンスと改善のために使用し続けました。

正常に機能しましたが、bashスクリプト、cron、およびantよりもハドソンを好んでいます。