使用している継続的インテグレーションフレームワークとその理由を教えてください。
非常に多くの異なる継続的インテグレーション（CI）フレームワークが世の中にあり、どれが最も人気があるのかと思います。あなたが働いている会社でどのフレームワークを使用しましたか？
あるCIフレームワークが他のCIフレームワークよりも人気がある理由はありますか？おそらく、これは、それが提供する機能、それに統合されるもの、またはおそらく単なるマーケティングに関係しているのでしょうか？
Javaおよび.netの世界では、Rubyまたはpythonと言うよりも、継続的インテグレーションが多く使用されているようです。これはなぜですか？
Hudson または Jenkins （後者は前者の分岐です）。理由：シンプル（インストールと使用が簡単）で、柔軟性に優れています。プラグインは、私が考えることができるほぼすべての機能を追加します。
数年前、私は damagecontrol を使用しました。使い方も簡単ですが、プラグインはありませんでした。しかし、著者は単純な解決策をあきらめて、互いに通信している異なるサーバーで構成される新しいバージョンの開発を開始することを決定しました（一体何ですか？）。それはうまくいかず、プロジェクトは断念されました。私はしばらくの間捜索していましたが、cruisecontrol（複雑すぎる）でも連続体でも本当に私を捕まえませんでした。ハドソンまで、それは私にとって最初の瞬間からうまくいきました。
私は TeamCity を職場と自宅で使用しています。さまざまなビルドランナーをサポートし、プラグインを介して拡張可能です。
構成用のXMLの山を扱わないことは私の本の大きなプラスであり、無料バージョンは私の家のニーズには十分です。
TeamCityで私が遭遇した1つの問題は、.NETアセンブリを自動的にバージョン管理できるようにすることです。比較的複雑な回避策を設定する必要がありましたが、それが導入されると、それは魅力のように機能しました。
個人的には、CruiseControlとCruiseControl.Netしか使用していません。この理由は、経済学に関係しています。それらは適度に安定しており、一度設定すると、維持するために必要なことはほとんどありません。通常、ユーザーコミュニティは非常に役に立ち、ニーズに合わせて拡張できます。
とは言え、私が知っている利用可能な商用製品がいくつかあります（1つはJetBrainsによるもの、もう1つはAtlassianによるもの）。これは、より優れたセットアップエクスペリエンスと商用サポートを提供します。私はこれらの製品を試すつもりでしたが、実際にはまだチャンスがありませんでした。
CIツールはインタープリター型言語よりもコンパイル済み言語の方が重要な役割を果たしますが、CIツールがインタープリター型言語で浪費されているわけではありません。相互に依存する複数のプロジェクトがあり、変更によって依存関係が誤って破壊されないようにする場合は、CIツールが非常に役立ちます。
CIツールで把握できる問題には、3つの一般的なクラスがあります。
- コンパイルエラー-依存関係を壊すような方法でクラスのシグネチャが変更された場合、成果物の時間がなくなる前にそれについて知ることが最善です。
- 論理エラー-依存関係を壊すような方法でクラスの動作が変化した場合は、早期にそれを知ることが最善です。これは、ある種の自動テスト、最も一般的には単体テストによってチェックする必要があります。
- 受け入れテスト-完成した製品で実行する自動化されたテストスイートがある場合は、テストを頻繁に実行することをお勧めします。
解釈された言語はコンパイルされないため、キャッチするコンパイルエラーはありません。ただし、他の2つの問題は、CIツールがRuby/Python/Perl/etcのプロジェクトに役立つほど一般的です。
論理エラーと受け入れテストポイントの両方のキーワードは、「自動化された」テストです。マシンで実行できる一連のテストがない場合は、CIツールの大きな利点を実際に利用できません。自動化されたスイートは時間をかけて構築できるため、小規模から始めることができます。
編集
多数のCIツールの機能比較については、このニースチャートを参照してください（多くは私が知りませんでした）：
http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix
ソリッドCI、Visual Studioとの緊密な統合、および バージョンコントロールとしてのGit 。 Hudsonのようなより柔軟なCIサーバーを見てきましたが、TFSは他の製品と緊密に統合されているため、エクスペリエンスが非常にシームレスになり、チームにとって理にかなっています。
CruiseControl.NETとHudsonの両方を使用しています。私のビルドのいくつかはそれらの1つにあり、いくつかは他のものにあります。
なぜ？私はビルドエンジニアではなく、ビルドエンジニアである彼がこのように設定したからです！
ビルドの設定方法やどちらの製品についての苦情にも問題はありません。私は、物事が実際にどのようにここにあるのかをあなたに報告しています。
UPDATE：回答を投稿して以来、Hudsonは分岐して Jenkins になりました。上記の推奨事項はJenkinsに適用されます。
パルス 。これは基本的にJust Worksであり、多忙なビルドエンジニアにとっては大きな問題です。彼らはまた、本当に優れた技術サポートを持っています。私がとても気に入っている主な理由は、250以上のプロジェクトがあり、問題なく処理できるためです。ハドソンについても同じことは言えません。
私たちのチームは主にPython、C++、Javaで動作します。 CIにはBuildbotを使用します。 Tracと統合されていて、シンプルでわかりやすいため、最初にそれを使い始めました。これは、Python=世界で選択されたCIフレームワークだと思います。
ハドソン。それは時々少しバグがあり、より興味深いプラグインのいくつかは実際には機能しませんが、少しの手持ちでそれはかなり使いやすいです。
私はおそらく代わりにPulseを使用しますが、複数のプラットフォームでビルドする必要がある場合は、$ 5kを超えます。
CruiseControl.NET継続的インテグレーション。 CruiseControlでセットアップした非常に多数のビルドプロジェクトがあるにもかかわらず、CCTrayデスクトップトレイアプリは、更新間隔が長い場合でもひどく応答しません。
NAntは、CruiseControlプロジェクトで実行されるビルドスクリプト用です。より複雑なビルドスクリプトについては、NAntをカスタムC＃NAntタスクで拡張しました。これは非常に素晴らしいことです。C＃でコードを書く方がNAntスクリプトを作成するよりもはるかに楽しいです。
私たちはマイクロソフトショップであり、Team Foundation Server環境を2010に移行すると、理論的にはMicrosoftのチームビルド2010に移行します。
CIエンジンを実行しているかどうかに関係なく、コマンドラインからアプリケーションをビルドできることに注意してください。
これは、CIエンジンが行うのはビルド呼び出しのシステム化だけであり、特定のニーズに最も適したエンジンを選択できることを意味します。
個人的には、主にHudsonが好きです"feels"いいのですが、すべてが失敗した場合、あまり努力せずに別のものに切り替えることができます。もしそうなら、私はおそらく最初にAtlassianによって作成されたものを調査します。なぜなら、私は彼らが作成する他のプログラムの"feel"が好きだからです。
互換性は、どの言語で書かれているかは関係ないことを意味していることに注意してください。Javaは、多くのエンジンがサポートされており、多くのプラットフォームがサポートされており、簡単に利用できる多くのビルディングブロックと組み合わされているためです。 Webサーバーが必要です-1つを取得します。多数の同時スレッドが必要です-それらを使用するだけです。拡張性が必要です-jarにドロップします。
「継続的インテグレーション」という言葉を耳にする前に（これは2002年または2003年に遡ります）、cvsに接続し、メインプロジェクトのクリーンコピーを取得する夜間ビルドスクリプトを作成し、5つの小さなサブプロジェクトをすべてビルドしました。次に、antを介してjarファイルを作成し、Tomcat antタスクを使用する2番目のantスクリプトを介してWARファイルを構築および再デプロイしました。
それは午後7時にcronを介して実行され、一連の出力ファイルが添付された電子メールを送信しました。プロジェクトの7か月間すべて使用し、メンテナンスと改善の次の20か月間使用し続けました。
それはうまくいきましたが、それでもbashスクリプト、cron、antよりもhudsonを好みます。