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

Question

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

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

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

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

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

gbjbaanb · Accepted Answer

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

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

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

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

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

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

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

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

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

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

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

pdr · Answer

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

最初はSource Controlです。

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

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

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

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

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

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

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

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

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

Andrei Zubov · Answer

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

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

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

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