実際の経験に基づいて、どの自動ビルド環境が優れていると考えるかをお聞きしたいと思います。.Net と Java の開発を計画しているので、これらの両方のプラットフォームをサポートするツールが必要です。
私はいろいろ読んで、スタックオーバーフロー開発で使用されるCruiseControl.NETと、さまざまな OS プラットフォームでさまざまなプログラミング言語に基づくビルドエージェントをサポートするTeamCity について知りました。では、これらの両方について実際の経験がある場合、どちらを好みますか?またその理由は何ですか?
現在、私はツールの使いやすさと管理のしやすさに主に関心を持っていますが、CC がオープン ソースであり、実行するプロジェクトが多数ある場合に TC がライセンスの対象となるという事実にはあまり関心がありません (なぜなら、私は少量のプロジェクトで必要です)。
また、上記を満たす他のツールがあり、それを推奨する価値があると思われる場合は、遠慮なく議論に含めてください。
私は、Cruise Control (Java バージョン) を生み出したツール以来、継続的インテグレーション ツールに取り組んできました。私はある時点でそれらのほとんどすべてを試しました。TeamCity でこれほど幸せになったことはありません。セットアップは非常に簡単で、それでも大きなパワーを提供します。ビルド時間、単体テスト数、合格率などを示すビルド統計ページは非常に優れています。TeamCity のプロジェクト ホームページも非常に価値があります。単純な .NET プロジェクトの場合、ソリューションがどこにあり、どのアセンブリにテストが含まれているかを TeamCity に伝えるだけで済みます (ソース管理の場所を除く)。また、いくつかの複雑な MSBuild スクリプトを使用し、ビルド チェーンを実行しました。TeamCity のアップグレードも 2 回経験しましたが、問題はありませんでした。
CruiseControl.NET もうまく機能します。セットアップはややこしいですが、歴史が長いため、Web 上で簡単に解決策を見つけることができます。CruiseControl.NET はオープン ソースであるため、好きなものを追加または変更することもできます。私はリリース以来 CruiseControl.NET を使用しており、cc.tray の初期のコードの一部を書きました (ありがたいことに、よく知っている人によって書き直されました)。
ThoughtWorks の Cruise も非常に良さそうに見えますが、乗り換える説得力のある理由は見当たりません。もし私が新しいプロジェクトを始めていたら、試してみようと思うかもしれませんが、TeamCity は単純なものを単純にし、複雑なものを非常に簡単にするという素晴らしい仕事をしてくれました.
編集: 数週間前に TeamCity 5.0 にアップグレードしたばかりで、これも簡単なアップグレードでした。これにより、改善されたコード カバレッジ機能と GIT サポートを利用できるようになりました。また、しばらくの間使用されていた個人用ビルドと事前テスト済みのコミット機能も使用しています。TeamCity が改善し続け、使いやすいことを示すために、回答を更新する必要があると思いました。
私は CC.NET の大ファンでした。現在、CruiseControl には 5 つのプロジェクトがあり、うまく機能しています。手動で設定ファイルを書くのは大変ですが、大丈夫です。
しかし。
Kona: Continuous Integration and Better Unit Testingスクリーンキャスト (TeamCity に関する最初の 1/3) の後、TeamCity もチェックします。統合された単体テスト ダッシュボードと構成インターフェイスが気に入っています。
CC.NET または TeamCity を選択する前に、誰もがこのビデオを見るべきだと思います。
ps:ネット上にも貴重なCC.NET動画があるといいのですが。
私のお気に入りの CI サーバーは Hudson です。セットアップと保守が簡単で、開発者と非開発者に傾向を示すための多くの優れたグラフがあり、無料です。
私は現在、プロジェクトで TeamCity を使用しており、概ね満足していますが、生成されるグラフの多くは特に有用ではなく、Hudson よりも構成が複雑です。
とはいえ、TeamCity は強力で、無料で多くの用途に使用でき、1 つの優れた機能である Remote Run を備えています。IDEA または Eclipse から直接チェックインを「事前コミット」し、TeamCity サーバーで 1 つ以上のビルド構成を実行し、ビルドが成功した場合 (たとえば、コンパイルしてすべてのテストに合格した場合) にのみ変更をコミットできます。
TeamCity と Hudson の両方を数時間で起動して実行できることを考えると、考えられる他のもの (CruiseControl など) と一緒に、両方を取得して並べて実行する価値があるかもしれません。CI サーバーをすぐに立ち上げて並べて比較することができない場合でも、少なくとも、インストールや構成を簡単にするためのデータ ポイントがあります。
CC.net と TeamCity の両方を使用しました。私は自分の組織 (5 人の開発者) のために TeamCity をセットアップしてインストールする任務を負っています。私たちの組織では、(少なくとも私たちの規模の組織では) いくつかの珍しい慣行とツールを使用しています。たとえば、ソース管理用の Perforce や異種オペレーティング システムで実行される複数のビルド エージェントなどです。ただし、電子メールによるサポートは、すべてをセットアップする上で絶対に一流でした. ばかげた質問に対する回答を文字通り数分で受け取りました。
インターフェイスは直感的で応答性が高く、機能満載です。商品はとても高く感じます。構成は簡単で、Web インターフェースは、エージェントやサーバー サービスを再起動したり、ページを更新したりすることなく、自分自身を更新するのに十分なほどインテリジェントです。
製品のほぼすべての高度な機能を使用しているように感じますが、これまでのところバグはまったく見つかりませんでした. Ndepend の統合、ネストされた NAnt スクリプト、Perforce のバージョンのラベル付けなど、私たちはそれを行っています。
継続的インテグレーション サーバーやビルド サーバーを探している人には、TeamCity を強くお勧めします。
私はそれらをさまざまなプロジェクトでうまく使用しました。セットアップと管理の観点からは、Team City の方がはるかに扱いやすいです。CC のように .config ファイルをいじる必要はなく、セットアップも簡単です。あなたは多くのプロジェクトを持っていないので、Team City の費用が $$ になるまでは、CC よりも Team City をお勧めします。
決定したシステムが、処理する必要があるプロジェクトの数に合わせて拡張できることを確認してください...
私は CruiseControl.Net を使用していますが、多くのプロジェクトを構築する場合にはお勧めしません...アプリケーションに構成する多くの C++ 静的ライブラリがある (おそらく少し奇妙な) 配置があります。各ライブラリは他のライブラリに依存しており、アプリは一連のライブラリをプルしてビルドします。各ライブラリにはテスト スイートがあります。各アプリにはテスト スイートがあります。5 つのコンパイラと (Windows) プラットフォームのバリエーション用にビルドします。
私が最初に見つけたのは、CC.Net のプロジェクト トリガーは実際には必要なものではなく、マルチ トリガーはプロジェクト トリガーとうまく連携しないということでした。プロジェクト トリガーが機能する方法 (リモーティングを使用して、プロジェクトが保存されているサーバーに接続し (それが CC.Net の同じインスタンスによって管理されているプロジェクトであっても)、そのサーバーからすべてのプロジェクトをプルし、リストを順番に検索します)。興味のあるプロジェクトを探している...) ということは、それらがうまくスケーリングできないことを意味します。プロジェクトの数が一定以上になると、CC.Net がビルド マシンの CPU のほとんどを使用していることがわかります。
もちろん、これはオープン ソースなので修正できます。また、少数の非相互依存プロジェクトには問題ないと確信しています。
私が抱えていた問題の詳細と CC.Net のいくつかのパッチについては、こちらを参照してください。http://www.lenholgate.com/archives/cat_ccnet.html
あなたに代替ツールを投げたくない場合:-)
Hudson は優れたオープン ソースの代替手段です。私は CC と CC.net を使用しましたが、これらは素晴らしいツールだと思います。hudson に切り替えることを検討しています。セットアップと保守がはるかに簡単なようです。
以前の会社で、Linux上でCruiseControl（Javaバージョン）をセットアップして実行した経験があります。ほとんどの人が示唆するように、それはセットアップするのが最も簡単なことではありません。実行可能/管理可能な構成を考え出すには、そのフレームワークを理解する必要があります。ただし、そのこぶを通過すると、CruiseControlは非常に柔軟で、さまざまなシナリオに合わせてさまざまな種類のことを実行できるようになります。
さらに、CruiseControlのドキュメント、そのwikiページにもいくつかの有用な情報があります。
TeamCityを直接経験したことはありません。テスト前のコミット機能は十分に興味深いように見えますが。
あなたがそれを見るかもしれない他のCCツールはAtlassianのBambooです。セットアップがはるかに簡単で、インターフェイスも優れています。ただし、CruiseControlが提供するものほど柔軟ではありません。
最近、cc .net をセットアップしました。これは素晴らしいアプリケーションですが、少し忍耐が必要です。メモ帳で多くの設定ファイルを編集します:)
しばらく前からサポートが充実しており、以前にやりたいことをやった人を見つけることができます。Web インターフェイスも .net であり、Microsoft ショップである私たちにとってプラスでした。
私は TeamCity を使用したことはありませんが、かなりの数の推奨事項を聞いており、見た目もきれいです。
検討したい 3 番目のオプションは、Thoughtworks のクルーズです。これは CruiseControl 上に構築されていますが、より多くの機能、簡単なセットアップなどを提供します。無料 (またはオープン ソース) ではありません。
http://studios.thoughtworks.com/cruise-continuous-integration
私は過去 1 年半 Teamcity を使用しており、素晴らしい経験をしています。私は多数の .Net および Java プロジェクトを統合し、MSBuild、Maven などのツールを使用しました。Teamcity のセットアップと操作は非常に簡単であることがわかりました。いくつかのSQLプロジェクトでもCIを実行することができましたが、これは少し悪夢でした.他のCIツールではさらに悪化する可能性がありました.
最近、痛みのない Teamcity 8.0.6 にアップグレードしました。また、Teamcity は、いくつかのシナリオで非常に役立つREST APIを提供します。ビルドの自動化に powershell を使用している場合は、 GitHubで多数の Psake/Teamcity 統合スクリプトを利用できます。