Team Foundation BuildまたはTeamCity？
私たちは、主に.NET LOB開発を行うMSショップです。また、CRMアプリにMS Dynamicsを使用しています。現在、すべての開発者がVS/SQL Server 2008を使用しています。VSSも使用していますが、誰もがそれを嫌っています。
チーム全体でTDDを実装するためのイニシアチブを開始しています（約1ダース）。 TeamCityのセットアップを取得し、2008 slnビルダーを使用して、また同僚がソース管理分析を行っているセットアップのSVNを使用して、最初の自動ビルドを正常に実行しました。管理にデモすると、彼らは私のヘビ油を買い始め、TFSを調べることの提案を捨て始めたと思います。
これは、私がTDDアーキテクチャ用に計画していたものにレンチを投げました。 TFSはあまりにも高価であり、私たちのチームにとっては価値がないと常に思っていたので、良い意味で（そして私が働いていた/知っている他の店でも同じように見えました）。 TDD/CI分野ではMSが何年も遅れているように感じます。サードパーティの製品はおそらくはるかに優れていて、より成熟していると思います。まだ多くの調査を行う必要がありますが、誰かが実際に両方のシステムを使用した場合。
TFSには単なるビルドサーバーよりも多くのことが含まれていることに気づきました...しかし、少なくとも意図的にこれをあまりにも広範にしたくはありませんでした。 TeamCityの代わりにTFS/TFBを使用する場合の実際の長所/短所は何ですか？たとえば、どのメリットを失う/得るのでしょうか？ CIおよびTeamCity/SVN）および実用的な観点から話すことができますか？
私はこのトピックでいくつかの検索を行いましたが、ここで見つけた1つの投稿SOは、TFBの短所はMSBuildのみをサポートしていたことを言及しました。 TFSもサポートしているようです...
アドバイスをありがとう
EDIT：誰もがTFSをBuild/CIサーバーとして使用し、成功/失敗ストーリーを伝えることができますか？
私たちは小さな開発会社であり、Team Foundation Serverのオーバーヘッドが大きすぎると判断しました。以前はコマンドラインから実行するカスタムMSBuildスクリプトを作成していましたが、TeamCityを発見した後、ビルドプロセス全体をそこに移行しました。
TeamCityは使いやすく、構成が簡単であることがわかりました。JetBrainsは優れたサポートとドキュメントを提供します。また、Microsoftよりもはるかに高速なリリースおよび更新サイクルにあります。
SVNソース管理のサポートは優れており、ユニットテストでMSTestとNUnitの両方をサポートしているという事実が気に入っています。
また、TeamCity Professionalエディションが無料であるという事実も気に入ったため、評価して、動作するかどうかを確認できました。 Enterpriseエディションにアップグレードする必要があるプロジェクト構成の数（20）には達していません。
この質問 にはTeamCityについて多くの良い回答があります。 TFSとは比較されませんが、TeamCityに光を当てる可能性があります。
私は両方を使用し、両方で成功しましたが、TeamCityは非常に簡単でした。 TeamCityはセットアップと構成が簡単でした。 TFSはそうではありませんでした。 TeamCityは堅実であり、保守が簡単で、単純に機能します。 JetBrainsの開発者は、コミュニティに対応して素晴らしい仕事をしました。 6〜8か月ごとにリリースされ、真の価値がもたらされます。 TFSは2年以上のサイクルです。
TeamCityを使用すると、構築方法と使用するソース管理の選択肢が広がります。それがすべてではありませんが、それは時々良いことです。拡張ポイントの優れたセットもあります。また、それが持つエージェントモデルに本当に満足しています。
私は、TeamCityで3つの非常に苦しいアップグレードを経験しました。 1つのTFSアップグレードで、ビルドとソース管理が3日間ダウンしました。私はこのプロジェクトのTeamCityの管理者であり、月に数時間かかります。 TFSは週に数日かかりました。
TeamCity + SVN + VisualSVNは、私が今まで働いた中で最もスムーズな環境でした。TFSは、通常、日常的にスムーズでしたが、誰かがそれを実行し続けていた場合に限りました。
役立つことを願っています
TFSの利点は、Microsoftによってサポートされている1つの統合環境です。私は個人的にソース管理にTFSが好きではなく、TFSに関して多くの問題を抱えています。ぎこちないですが、VS統合（VisualSVNでも利用できますが、それほど堅牢ではありません）があるという利点がありました。
個人的には、SVN/TeamCityを使用した方がずっと良いと思います。作業が簡単になり、期待どおりに動作します。ほとんどのオープンソースソフトウェアと同様に、どちらも絶えず進化しており、Microsoftよりも前に常に最新かつ最高の機能を備えています。 2つの統合は非常に良く、システムに致命的な欠陥は見つかりませんでした。私は現在の会社（TFSを使用しています）でこのルートに進むように常にプッシュしています。追加の利点として、TFSルートを使用するよりも大幅に安価です。
また、TFSでFinalBuilderを使用しました。NANT/ MSBuildではできないFinalBuilderで実際に何を購入するのかという質問があります。私の店での答えは、残念ながら非常に少ないIMOです。
まず、この投稿を参照してください。
どの環境がTDDを促進するかなどについてのあなたの質問について、私の2セントは、ビルド管理システムがビルドファイル自体にあるものよりもはるかに重要ではないということです。 AntまたはMSBuildファイルには、テストを実行するターゲットが含まれている必要があります。 MSBuildまたはAntを使用すると、MSのテストスイートを使用する必要はありません。 nUnitまたはその他の必要なものを引き続き使用できます。つまり、TFSがMSBuildファイルを呼び出しているか、CruiseControlが呼び出されているか、TeamCityが呼び出されているかは関係ありません。スマートはすべてビルドファイルと、それと統合するツールに含まれています。
私が個人的に選択しているのは、TFSのやり方に縛られることではありません。なぜなら、豊富なオープンソースのテストツールを使用すれば、はるかに多くの自由をより少ないコストで得られるからです。 TFSはメジャーアップグレードも受けようとしています。 TFSを使用する場合は、少なくとも2010がリリースされるまで待つことをお勧めします。 MSBuildファイルをできる限り良いものにすることに集中してください。
そうは言っても、TFSには最も優れたビルドシステムの1つがあることを認めなければなりません（2005年はひどく、2008年はすてきでした）。 .NETコード内のすべての通知とリリースプロセスを簡単にカスタマイズできることは非常にクールでした。CruiseControl.NETを使用した場合よりも、ビルドポリシーとリリースポリシーを集中管理できました。
だから私はTFSとSVN/CCNetを使用しました。 TeamCityとはあまり話せません。しかし、ビルド管理システムであるIMOは、何がどのように構築され、どのように構築されているかについてはかなり非依存的でなければなりません。私たちにとって、TFSがもたらしたリリース管理プロセスの追加制御は、完全に統合されたTFSソリューションの大幅に増加した管理作業を正当化するのに十分なボーナスではありませんでした。また、TFSのライセンスごとの追加コストを正当化するだけでは十分ではありませんでした。
古いTFSビルドはXAMLベースで非常に面倒であり、使用するのに適していません。とは言っても、新しいTFS 2015ビルドシステムは飛躍的に向上し、多くのWebフックとサードパーティの統合を備えたスクリプトベースです。チームシティに非常に似ています。また、TFSはGitをサポートするようになったため、Team Foundation Version Control（TFVC）の使用に限定されなくなりました。また、TFSを使用すると、独自のオンプレミスインストールを使用したり、visualstudio.comからホストされたソリューションを利用したりできます。 TFSは完全に統合された1つの環境（作業項目、計画、ビルド、テスト、展開）であり、Team Cityは単なるビルドソリューションであるため、素晴らしいです。 2010年にこの質問が最初に尋ねられたとき、Team Cityの伝承をお勧めします。しかし今、2つは非常に競争力があります。オールインワンソリューションが必要な場合は、TFSを使用することになるかもしれませんが、純粋にビルドシステムを探している場合は、Team Cityを探します。
TeamCityとVisual Studio Team Services（Microsoftの最新のクラウドベース製品）の比較：
両方とも、継続的な統合プロセスの実装に最適です
TeamCityはより成熟しており、すべてが機能します。
対照的に、Visual Studio Team ServicesはTeamCityに追いつくために絶えず進化しており、いくつかはうまく機能しません（たとえば、Gitからの変更があるパスに基づいてビルドをトリガーしようとします-ドキュメントが弱く、機能自体が機能しません） （2016年8月現在））
Visual Studio Team Servicesを使用すると、クラウドベースのエージェントのみでビルドを簡単に実行できます（ただし、欠点は、ビルドごとにリポジトリをきれいにプルする必要があるため、ビルドに1分以上かかることがあります）。どちらもローカルビルドエージェントをサポートできます。ローカルビルドエージェントは、新しいビルドごとに作業ディレクトリを消去する必要はありません。
しかし、どちらの場合でも、howに関するほとんどの構成情報を移動して、CIシステムからGitリポジトリにあるC＃コードにビルドするCakeBuildを参照することを強くお勧めします。他のすべてのソースコード。 CakeBuildを使用すると、CIシステムで実行するのと同じビルドをローカルで実行できます。特定のバージョンをビルドするために1か月前に戻る必要がある場合は、ソースコードとそれを実行するビルドスクリプトがあります。
CakeBuildを導入すると、TeamCityとVisual Studio Team Servicesを簡単に切り替えることができます。
CakeBuildの唯一の欠点は、すべてのビルド手順がCIシステムの単一のタスクにバンドルされることです。これにより、レポート作成が少し少なくなり、CIレポート作成システムが使用できる形式にテスト結果を取得するための追加作業が必要になる場合があります。
MSはTDD/CI分野で数年遅れています
4年間TDDを経験した人であることは正しい。 MSはそれをまだ宣伝しておらず、TDDフローとうまく機能するツールも提供していません。
あらゆる種類の自動化、ソース管理、またはアジャイルワークフロー期間でVisual Studioの処理にこだわらないでください（TFSの使用を中止してください!!）。彼らは「新しい」と言っても、それはモノリシックであり、常に奇妙な問題と肥大化が伴います。いつもつらいです。
私はTeam Cityを使用しましたが、それは単に驚くばかりで、機能し、使いやすさのために設計されており、ほとんどすべてのテストツールと互換性があります。コードにはVisual Studioを使用します。より良いCIの構築に役立つ外部ツールおよびオープンソースツールを探します。 「VSですべてを正しく実行できる」販売は販売ではなく、機能していません。今日の人々は、物事を成し遂げるために、外部からのさまざまなツールを常に使い慣れています。すべてのMSツールセットに依存することは、IMO for .NETを使用する方法ではありません。 MSは、「ここで何でもできます」を販売するのが好きです。しかし、そのルートに行って彼らのクーラード（TFS、MSフェイクスなど）を飲むと、痛み以外の何ものでもなくなります。
TDDの実行を計画している場合、すべてのMSツールを使用することは絶対に望まないでしょう。ツールを使用してTDDを実行しようとすると、多くの場合プロプライエタリおよび/または肥大化することを行う「彼らの方法」にプッシュされるか、完全に制限されます。 TDDの場合、さまざまなテストフレームワーク、アサーションライブラリなどに階層化することを決定するときに、ある程度の柔軟性と選択肢が必要になります。
Team Cityの上に Octopus を追加すると、それは素晴らしい...開発者として、またはDevOpsを実行している人なら誰でも簡単に恋に落ちるでしょう。
アジャイルツールの提供でMicrosoftの継続的な失敗に頼ろうとするのをやめる
私は過去に.NET開発者であり、MSの世界の外で新しいことを試みたことがあります。