23

私たちのチームは、夜間の継続的な統合ビルドをセットアップしています。私たちは Team Foundation Server を所有しており、Team Foundation Build を使用できます。私は CC.Net に慣れており、そのように傾倒していますが、経営陣は TFS に費やされたすべてのお金を見て、それを使用したいと考えています。

CC.Net について私が気に入っている点は、通知の柔軟性と、カスタム スクリプトの実装の容易さです。

両方の製品を使用した経験がある場合、どちらを好みますか?その理由は?

4

5 に答える 5

30

私は両方を使用しました。それはあなたの組織の価値観に依存すると思います。

あなたは CC Net に精通しているので、私はそれについて多くを語ることはしません。あなたはすでにそれをクールにするものを知っています.

Team Foundation Build の気に入っている点は次のとおりです。

  • ビルド エージェント。任意のボックスをビルド マシンに変えてビルドを実行するのは非常に簡単です。MSFTはこれを正しく理解しました。
  • 報告。関連するすべてのビルド結果 (テストを含む) は SQL データベースに保存され、SQL Server Reporting Services を介して報告されます。これはビルドとテストの結果を経時的にグラフ化するための非常に強力なツールです。CC Netにはこれが組み込まれていません。
  • MSBUILD を介して同様のカスタマイズを行うことができます。CC NetでNAntを使うのと基本的には同じです

Team Foundation Build について私を突き動かすものは次のとおりです。

  • C++/CLI プロジェクトをビルドする (または単体テストを実行する...?) には、ビルド エージェントに VSTS Dev または Team Suite がインストールされている必要があります。これは、友達、ただのクレイジーです。
  • TFSマザーシップに接続する必要があります

莫大な予算を持ち、レポートを愛する多くの上司がいる大規模な組織にいる場合 (誤解しないでください。これには大きな価値があります)、またはマルチマシン ビルド ファームにスケールアップする必要がある場合は、 Team Foundation ビルドを優先します。

無駄のないショップの場合は、CC Net を使い続けて、独自のレポート ソリューションを構築してください。それが私たちがしたことです。

取得するまで。そしてTFSを手に入れました：P

于 2008-09-17T05:16:03.920 に答える
13

TFS を所有しているので、バージョン管理に使用することになると思います。その場合、私は Team Foundation Build に傾倒します。そうは言っても、私はニックにかなり同意します。

TFSのCruiseControl.NET 統合を作成しました。それは正常に機能し、慣れ親しんでいるのと同じビルド機能を提供します。私にとって、CC.NET の主な利点は、完全に拡張可能であり、太陽の下ですべての主要な SCM およびビルド システムと統合されていることです。私が CC.NET 統合を TFS に記述した主な理由は、TFS2005 ではビルド システムにすぐに使える CI サポートがなかったためです。ただし、TFS2008 バージョンは大幅に改善されており、チームは TFS の将来のリリースに向けて非常に積極的に改善を続けています。

TFS ビルドに切り替える主な理由は、ビルド情報を TFS に自動的に報告し、レポートの観点からソフトウェア開発の全体像を完成させるのに役立つためです。また、TFS の作業項目追跡側および IDE 内部 (Visual Studio と Eclipse の両方) ともうまく統合されます。

とはいえ、コードをコンパイルしてテストする以上のことを行う Nant スクリプトに多額の投資をしている場合、または自家製のレポート ソリューションを既にお持ちの場合は、お持ちのものを使い続けることをお勧めします。

于 2008-09-17T06:23:21.307 に答える
5

Team Foundation ビルドの真の価値は、変更セットと作業項目をビルドに関連付けることです。

これにより、いくつかの便利なシナリオが可能になります。

  • ワークアイテムを見て、それがどのビルドに含まれているかを調べることができます
  • ビルドを見て、どのコード変更 (および作業項目) が含まれているかを確認できます。

もちろん、この情報に基づいて作成されたレポートもあります。しかし、これらのリンク自体でさえ、非管理タイプには役立ちます。

さまざまなチーム ビルド構成の「レシピ」については、www.tfsbuild.com を参照してください。

于 2008-09-17T07:21:36.970 に答える
4

SVN は OK のツールであり、はるかに優れているというのは真実ではありません。SVN と TFS は、フォードのピックアップとメルセデス 500 の比較に似ています。仕事は完了しますが、きれいでも快適でもありません。マージには多くの要望があります。分岐開発者があなたと一緒に働いているように見えるので、私はTFSマージツールを好みます。それはそれがどれほど賢いかです。私たちの内部 SVN はかなり壊れているように見えました。これが、私たちがそれを捨てて TFS に行き、振り返らなかった理由です。変更セットの棚上げは、アジャイル開発ショップにとって素晴らしいことです。現在、TFS に 270 人以上のエンジニアがいて、問題も問題もありません。SVN は、誰かに問題がなければ、その種の負荷を処理できませんでした。

私が CC.NET を好むのは、レポートと管理の機能を拡張するために社内で開発したツールがあるからです。ただし、TFS ビルドは非常に密接に統合されており、SQL 2008 にアップグレードするときに切り替えが予想されます。

于 2009-04-28T17:36:04.000 に答える
3

2007 年 6 月から CruiseControl.net を使用しており、非常にうまく機能しています。最良の部分は、はるかに優れたソース管理プロバイダーである SVN に簡単に統合できることです。

したがって、セットアップは次のとおりです。

私たちはいくつかの主要な並行開発を進めており、分岐とマージの経験は素晴らしいものでした。選択肢があれば、上記のセットアップを使用します。

于 2008-09-17T05:08:13.097 に答える