最善の方法：既存のTeam Foundation Server（TFS）ソリューションを再構築する

私の部署では、ユニファイドコミュニケーションサーバー用にいくつかの小さなアドオンを開発しています。バージョン管理と分散開発では、Team Foundation Server 2012を使用します。

ただし、すべてのアプリケーションとライブラリに対応する大規模なTFSソリューションは1つだけです。

• 主な解決策
  • 用途
    
    • アプリ1
    • アプリ2
    • アプリ3
  • 外観
  • 図書館
    
    • Lib 1
    • Lib 2
  • 道具

「アプリケーション」パスには、すべての主要なアプリケーションが含まれています。これらは互いに依存していませんが、ライブラリと外部プロジェクトに依存しています。

「外部」パスには、アプリケーションとライブラリで参照される外部DLLが含まれています。

ライブラリパスには、一般的に使用されるライブラリ（UIテンプレート、ヘルパークラスなど）が含まれています。これらは互いに依存せず、ライブラリおよびツールプロジェクトで参照されます。

ツールパスには、セットアップヘルパー、更新Webサービスなどのヘルパープログラムが含まれています。

さて、この構造を変更したい理由はいくつかあります。

• サーバービルドは使用できません。
• そのようなソリューション構造で、スプリント、障害などでTFSスクラム管理を管理するのは不快です。
• すべての開発者は、ソリューション内のすべてのプロジェクトに常にアクセスできます。
• Visual Studioで誤って[F6]を押した場合、完全なビルドが長すぎます...

このソリューションで何を変更しますか？それらのプロジェクトをより小さなソリューションにどのように分割し、それらのソリューションをどのように構成すべきですか

最初のアプローチは、アプリケーション、ライブラリ、およびツールごとに1つのTFSプロジェクトを作成することです。しかし、たとえばApp 2に常に最新バージョンのLib 1が含まれていることを確認するにはどうすればよいですか？Lib 1の変更を監視し、Libが変更されたらすぐにApp 2を手動で更新する必要がありますか？または、何らかの方法でVisual Studioに常に外部プロジェクトの最新バージョンを常に使用させることができますか？

編集： TFSには、1つのTFSチームプロジェクトを含むTFSチームプロジェクトコレクションが1つだけあります。チームプロジェクトには、1つの大きなVisual Studioソリューションが含まれています。このソリューションには、複数のVSプロジェクトを含む複数のフォルダー（上記の構造を参照）が含まれています。

私の質問は今、どのように再編成しますか：

1. TFSチームプロジェクト
2. VSプロジェクト

1つのTFSチームプロジェクトに固執すると、アップグレードしようとするときに複数になることは苦痛になり、チームプロジェクトのワークアイテムを横断する場合にはいくつかの制限があります。代わりに、エリアと反復を多用する必要があります。

VSソリューションを複数のソリューションに分割します（主要アプリケーションごとに1つ）。これにより、ビルドサーバーだけでなく、ローカルビルドも大幅に高速化されます。

TFS2012には、チームと呼ばれる新しい概念があり、アプリケーションごとにチームを作成し、それぞれにデフォルトの反復とバックログを設定します。これにより、それぞれのバックログを管理したり、ルートチームを表示してロールバックされたバックログを確認したりできます。その後、スプリントをアプリケーションレベルで管理することも、自分に合ったものに応じて全体的に管理することもできます。

まだ持っていないすべてのサードパーティ参照ライブラリのNuGetパッケージを作成します。それらをプライベートリポジトリ（Windows共有フォルダー）に保存し、すべてのソリューションを右クリックして有効にすることでNuGetのパッケージ復元機能を有効にします（パッケージの復元でvs設定でパッケージをダウンロードできるようにします）。

共有内部ライブラリがある場合は、それらのためにNuGetパッケージも作成し、そのライブラリのみを含むvsソリューションを作成します。ポストビルドコマンドを追加してnugetパッケージを作成するか、tfsビルドテンプレートを拡張してそれを実行します（既にこれを実行するテンプレートが多数あります）。