Team Foundation Serverへの移行を評価する方法

私の開発チームは現在、ワークフローで次のソフトウェアを使用しています。

• ジラ
• Bamboo（アトラシアン連続統合）
• Greenhopper（アトラシアンのアジャイルプロジェクト管理）
• 合流
• Git、BitBucketでホスト
• Visual Studio 2012

ご覧のとおり、私たちはアトラシアンのエコシステムにかなりの投資をしています。コードレビューなどの高度なVisual Studioインテグレーション、さらに重要なことにはMicrosoftテストマネージャーを利用できるように、TFSへの移行を検討しています。

私の以前のTFSの経験は2005年または2008年でした（覚えていません）。ClearCaseでの時間ほど悪くはありませんが、それについては悪い思い出があります。

TFSへの移行を適切に評価するために、どの基準を検討する必要がありますか？

マーティンファウラーの小さな調査は、過去のTFSの状態について多くを語っています。「危険」はかなり正しいです。（これは、VSの外部で行われた変更を認識しない方法を参照していると思うので、WCFプロジェクトを作成し、外部のsvcutilツールを使用してクライアントを作成し、すべての変更をチェックインできます。しかし、TFSはクライアントの変更はVS内で行われなかったため、喜んで無視してください）。

あなたはコストを数える必要があります：良いものを手に入れるために必要なVSのバージョン-例えば、コードレビューは、MSDN経由でVSを入手した場合、かなり高価なプレミアム版を必要とします。また、非VSユーザーのシステムへのアクセスは問題ありませんが、削減されたWebビューではなくフルアクセスが必要な場合は、CALを取得する必要があります。TFSの全体的なコストはかなり高くなる可能性があります。最近のForresterレポートでさえ（マイクロソフトから委託されているため、少し間を読む必要があります）TFSには重要な管理サポートが必要です-122ユーザーのケーススタディでは、2人のコンサルタントと6人の管理者（時間の25％を費やした）がTFSをサポートする必要がありました（これらの122人のユーザーに対して4.5人の管理者に対応します...これは、私が完全なSVNソリューションをセットアップして維持している間に、私の毎日の仕事もしているのと比較して、非常に多くなっています）。TFSは、人々が期待するとおりに機能し続けるために多くの労力を費やすことができます。

TFS2012での私の経験では（以前のバージョンは駄目なので忘れてください）、これは、特に事前定義された設定から外れた場合、システム管理が非常に複雑になります。たとえば、MSBuildを使用してすべてをビルドする場合は問題ありません。ただし、MSBuildでサポートされなくなった古い.vdprojプロジェクトが大量にある場合は、巨大なxamlビルドスクリプトを編集して、これらのプロジェクトをビルドする必要があります。これに取り組んだ数日後、私ができる最善のことは、devenvに渡してソリューションを再構築することでしたが、それでも、ビルド結果をビルドサマリーに取得することは不可能でした。テストにNUnitを使用した他のチームでも同様の結果が得られました。組み込みのMSTestを使用すれば、動作します。そうでなければ、あなたはかなり詰め込まれています。

ユーザーとして、私は統合がより厄介であることに気づきます。私はTortoiseSVNを好み、それを介してほとんどすべてのSCM作業を実行します（これは素晴らしいツールであるため）。TFSを使用すると、すべての操作でVS内に新しい画面が表示されます。したがって、環境内にチームエクスプローラ用の新しいタブがあり、ビルド用のタブが1つあります。また、表示したいビルドの概要ごとに別のタブがあります（ビルドの詳細、たとえばエラーを表示したい場合は、クリックしすぎるリンク）。TFSを使用しているときに開いていたドキュメントの数がソースファイルよりも多いことがわかりました。

同じことがチェックインにも当てはまり、変更をコミットするには、VSの[保留中の変更]ペインのいくつかのタブをクリックして、チェックインに作業項目とコメントを割り当てる必要があります。それは小さなことですが、より合理化されたツールに慣れていたので、私はそれが面倒だと感じました。

ビルドシステムの拡張は、もう1つ欠けている領域でした。xaml構成のため、ビルドに新しい機能を追加することは困難であり、それらの機能の結果をビルド画面に取り込むのは非常に難しいか、不可能です。したがって、コードの複雑さや静的分析などの要素を追加したい場合や、セレンやデプロイメントなどを介して自動テストを実行したい場合は、忘れてください。これらの側面にMicrosoftツールを使用している場合を除き（fxcopなど）。

ワークフローの更新はもう1つの問題でした。パワートイズは非常に役立ちましたが、ワークフローを正しく設定するのは依然として厄介であり、実際に表示したい情報でスクラムボードを構成することはできません。繰り返しますが、デフォルトまたは何もありません。 。

マージも苦痛でした。MSがTFSにgitを採用した非常に良い理由があると思います（これは新しいTFSプロジェクトでのみ機能し、TFSからgitバックエンドに変換できないことに注意してください）。

つまり、全体としては機能するのでそれほど悪くはありませんが、他の多くのツールの方がはるかに優れていることがわかりました。これらのツールの欠点は、完全に統合されていないことですが、IMHOは、必要な最良のビットを選択して選択できるという強みです。TFSを使用すると、他の誰かがあなたに望んでいるものをほとんど手に入れることができます。TFSのバグシステムが貧弱であると判断した場合（そうなると思います）、別のシステムに変更するのは難しいでしょう。

TFSは、他の大きくて太いフルライフサイクルツールと一緒に検討する必要があります。ほとんどの開発者は、これらのツールが最終的に課す制限を嫌うので、そのようなことを嫌います。

でも試してみて、30日間の試用版をダウンロードしてインストールします。評価するときは、あちこちを少し変更することを忘れないでください。ソースコードのチェックインに使用するだけでなく、必要な作業項目でチェックインして、その作業項目に基づいたレポートを取得してください。複数の作業項目にチェックインを割り当てて、関連する作業項目を組み合わせてみてください。ビルドシステムに別のものを組み込み、レポートサービスから毎日の進捗レポートを取得する方法を確認し、ドキュメントをワークフロー要件にリンクし、バグのトリアージを介してビルドし、ビルドしてやり直してからリリースするようにコーディングします。分岐してたくさんマージします。これらすべてを簡単に行うことができない場合は、gitを使用することもできます。ALMの機能のほとんどを利用しない場合、TFSを使用する意味はあまりありません。

大部分がアトラシアンスタック（およびMercurial）の会社から、重いTFSスタックの会社に移動しました。2つの苛立ちを見つけます。

1つはソース管理です。

DVCSに慣れてきたら、CVCSに戻すのは大変です。TFSは、その統合がすべて機能するために、常にサーバーに接続することを要求するため、特に痛みを伴います。

ただし、ありがたいことに、最近マイクロソフトはGitバージョン管理を残りのTFSスタックに統合することを許可しました。したがって、Gitをあきらめる必要はありません。誰もがすでにGitを知っているのであれば、Gitをあきらめる必要はありません。

コードレビューツールがGitに対してどの程度適切に機能するかはまだわかりません。シェルトセットに大きく依存しているようです（スタッシュのように少し強力ですが）。ただし、コードレビューをシェルフセットに依存すること自体は、定期的なコミットを妨げるため、それ自体が苦痛です。

その他の苛立ちは、ほとんどの人がTFSからの移行を検討しない理由です：Visual Studio Integration。

私はこれの背後にある認知的推論をまだ理解していませんが、私の経験では（これが一般化していることを考慮に入れて）、TFSに慣れている人々は統合を愛しています。彼らは何のためにIDEの外に移動することを好みません。

一方、私は1年経っても暖まりません。ビルドサーバーを1つのブラウザータブに配置したり、チケットを別のブラウザータブに配置したりする場合と比較すると、散らかっていてナビゲートが難しいと感じています。（編集：Andreiが指摘するように、Webインターフェースはありますが、JiraやJenkinsの最新バージョンに慣れていると、どういうわけか不格好です。しかし、それでも、現在は少なくともIE以外のブラウザーで機能します。したがって、それは何かです。）

ビルドしようとしない限り、ビルドを見ることはありません。そのため、他の誰かが既にビルドを行っているかどうかを見つけるのは困難です。確認を求められない限り、他の人の変更は表示されません。

しかし、あなたの距離は異なる場合があります。私が言うように、一部の人々はそれが不可欠だと思うようです。私はそれが別の方法でそれをやったことがない人であることに気づかざるを得ません。

また、かなり大規模なインフラストラクチャでは、これが2つのネガティブであり、そのうちの1つは個人的なものである可能性があることに注意してください。私の経験のほとんどは良好であり、TFSは一部の人々があなたに信じさせるほど悪くはありません。そして、あなたが見逃しているもののほとんどはおそらくオンにすることができます（それは非常に設定可能です）。1人ではなくチーム全体を移動する場合、抵抗が少なくなる可能性があります。

私はTFS 2012の使用について非常に前向きな経験をしています。TFSサーバーの設定と実行は非常に簡単で、CIビルドの自動化は非常にシンプルで簡単です（そして、ゲートチェックインビルドは素晴らしいだけです。同じ機能を実現できませんでした。チームシティと一緒に）。チームの相互作用も非常に透過的で簡単です。チェックインをTFS作業項目に関連付けたり、バックログを管理したり、不具合を追跡したり、コードレビューを行ったりすることが簡単にできます。=）にはメッセンジャーのビルドもあります

ただし、JIRAのワークフローに慣れている場合は、TFSワークフローの設定が困難な作業になる可能性があることに注意してください。事前定義されたTFSワークフローの1つを採用することをお勧めします。また、知識ベースとしてConfluenceを維持するか、TFSに組み込まれたwikiがないため、SharePointに切り替える必要があります。

MSDNサブスクリプションをお持ちの場合（MSテクノロジスタックを使用しているほとんどの開発会社がそれを持っていると思います）、TFSは無料です。

すべての開発者がVisual Studioを使用している場合は、サイドパーティツールを使い続ける理由はないと思います。TFSは、統合された堅牢でありながら使いやすいALMシステムを提供します。ご不明な点がございましたら、喜んでお答えいたします。

TFSは単なるVCSではなく、ALMです。

多くの人々がただVCSを望んでいるようですが、TFSを選ぶのは間違った方法です。
CVCSについては、私はまだSVNを好みます。
ソロまたはオープンソースの場合は、必ずGITを使用してください。

しかしTFS2012は悪くありません、それはマージ/フォークそしてSVNで簡単に理解できます。
また、チームファンデーションサービスは5ユーザー/無制限のプライベートリポジトリで無料です。

クライアントも無料で、TFSエクスプローラーはVS2010の上に構築され、無料です。
Eclipseの場合、Eclipseプラグイン-TFSがどこにでもあります。

コストの問題はないようです。
TFSエクスプレス（無料）はSQL Server Express（無料も）で使用できます。