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