TFSチェックインポリシー-ベストプラクティス
TFSチェックインポリシーを適用するためのベストプラクティスはありますか？さまざまな種類のポリシーとその長所と短所を実装する方法に関する優れたガイドはありますか？
私が特にやりたいことは、コードのコンパイル（コンパイルには最大5分かかる可能性があることに注意）と、コーディング標準の明らかなビット（要約タグが存在する必要がある、命名規則に従うなど）に従うことです。
TFS 2010（および2008ですが、2008は使用していません）では、ゲートチェックインが許可されています。これにより、ビルドがチェックインされる前にビルドが強制されます。
これをアクティブ化することは（合理的に）簡単なプロセスです。たとえば、次のガイドを参照してください。 http://blogs.msdn.com/b/patcarna/archive/2009/06/29/an-introduction-to-gated- check-in.aspxhttp://intovsts.net/2010/04/18/the-gated-check-in-build-in-tfs2010/
このすべての前に、これをすべて実現するために必要なステップがあります。これはTFSビルドサーバーのセットアップです。これは、インフラストラクチャなどによっては複雑なプロセスになる可能性があります。MSDNガイドは次のとおりです。 http://msdn.Microsoft.com/en-us/library/ms181712.aspx
長所は、リポジトリ内のコードがかなり安定している可能性があることです。大規模なチームの場合、これにより多くの時間を節約できます。
この利点について検討する価値のある多くの短所があります。まず、追加のビルドサーバーのインストールとメンテナンス。これには、ディスクスペースの割り当て、パッチなどが含まれます。次に、各ユーザーがファイルをチェックインするために必要な余分な時間です。コードがチェックインされる（そして他の人が取得できるようになる）前にビルドが成功するのを待つのは、しばらく時間がかかる場合があります。第三に、ビルドサーバーが利用できない場合（そうでない場合）、開発者が作業を継続できるように緊急時対応計画を立てる必要があります。
ゲートチェックインの報酬を獲得するには、多くの追加プロセスが必要です。ただし、このプロセスは適切に管理されているため、開発サイクルがはるかにスムーズになります。
ゲートチェックインは使用しませんが、スケジュールされたビルドを実行するための継続的インテグレーションにはTFSビルドサーバーを使用します。これにより、ビルドサーバーへの依存関係が分単位で最小限に抑えられ、ビルドが壊れた後、通知を受けてできるだけ早く修正できるようになります（かなり効果的です）。この方法により、開発者はコードの統合と、リポジトリ内のコードの破損を回避する方法を理解できます。
この質問の前提はやや間違っていると思います。この性質の良い質問は、次のようなものでなければならないと思います。私のチームは、コードの安定性、変更セットの競合、開発者がテストを実行していない、カバレッジが不十分、または管理者への他のメトリックレポートに問題がありますそしてそれを解決するためにTFSを使用したいと思います）問題。はい、私はOPがコンパイルを確実にすることが目標と見なされると述べたことを理解していますが、それは自動化されたビルドサーバーを持つことの一部です。
明確な目的がなくても、開発者の作業サイクルに摩擦を加える機能については疑問があります。私はそれらを使ったことがありませんが、ゲートチェックインは問題を探すための機能のように聞こえます。コードベースの安定性が開発者の生産性に影響を与えており、ソフトウェアの構成化、開発チームの構造、またはより優れた分岐戦略を変更しても修正できない場合は、それが解決策だと思います。 ClearCaseが必須のツールであるグローバルプロジェクトで大規模なショップで働いていて、そのような企業による失敗に遭遇しましたが、私が取り組んだチームは静かにまたは進んでそこに行きませんでした。
理想的なポリシーは、それを持たないことです。開発者が抑制されずに、できるだけ摩擦を少なくして作業できるようにします。コードレビューは、魂のないサーバーによって実施される一連のルールよりもはるかに多くのことを行います。テストをサポートし、適切に構成されたチームは、ゲートチェックインがこれまでに達成するよりも安定性のために多くのことを行います。分岐とローカルチェックインをサポートするツールを使用すると、開発者はビルドを壊すことを恐れずに新しいことを簡単に試すことができ、大規模なプロジェクトを殺すような技術的負債を軽減できます。
「パターンとプラクティス：Visual Studio Team FoundationServerを使用したチーム開発」の第8章を参照してください。