私の部門では、いくつかのユニファイドコミュニケーションサーバー用にいくつかの小さなアドオンを開発しています。バージョン管理と分散開発には、Team Foundation Server 2012を使用します。
しかし、私たちのすべてのアプリケーションとライブラリには、1つの大きなTFSソリューションしかありません。
「アプリケーション」パスには、すべてのメインアプリケーションが含まれています。それらは相互に依存していませんが、ライブラリと外部プロジェクトに依存しています。
「外部」パスには、アプリケーションとライブラリで参照されるいくつかの外部DLLが含まれています。
ライブラリパスには、一般的に使用されるライブラリ(UIテンプレート、ヘルパークラスなど)が含まれています。それらは相互に依存せず、ライブラリおよびツールプロジェクトで参照されます。
ツールパスには、セットアップヘルパー、更新Webサービスなどのいくつかのヘルパープログラムが含まれています。
さて、この構造を変更したいのにはいくつかの重要な点があります。
このソリューションで何を変更しますか?それらのプロジェクトをどのように小さなソリューションに分割し、それらのソリューションをどのように構成する必要がありますか。
最初のアプローチは、アプリケーション、ライブラリ、ツールごとに1つのTFSプロジェクトを作成することです。しかし、どうすればそれを保証できますか?アプリ2には常に最新バージョンのLib 1が含まれていますか? Lib 1の変更を監視し、Libが変更されたらすぐにApp 2を手動で更新する必要がありますか?または、どうにかしてVisual Studioに常に外部プロジェクトの最新バージョンを常に使用させることができますか?
編集: TFSには、1つのTFSチームプロジェクトを含む1つのTFSチームプロジェクトコレクションしかありません。チームプロジェクトには、1つの大きなVisual Studioソリューションが含まれています。このソリューションには、複数のVSプロジェクトを含む複数のフォルダー(上記の構造を参照)が含まれています。
私の質問は今、どのように再編成しますか:
1つのTFSチームプロジェクトを使い続けると、アップグレードしようとすると複数の作業が面倒になり、クロスチームプロジェクトのワークアイテムに関してはいくつかの制限があります。代わりに、エリアと反復を多用する必要があります。
VSソリューションを複数のソリューションに分割します(主要なアプリケーションごとに1つ)。これにより、ビルドサーバーだけでなく、ローカルビルドも大幅に高速化されます。
TFS2012にはチームと呼ばれる新しいコンセプトがあり、アプリケーションごとにチームを作成し、それぞれにデフォルトの反復とバックログを設定します。この方法で、それぞれのバックログを管理したり、ルートチームを表示してロールバックされたバックログを確認したりできます。次に、スプリントをアプリケーションレベルで、または全体に応じて全体的に管理できます。
まだ持っていないサードパーティの参照ライブラリすべてにNuGetパッケージを作成します。それらをプライベートリポジトリ(Windows共有フォルダー)に保存し、すべてのソリューションを右クリックして有効にすることで、NuGetのパッケージ復元機能を有効にします(パッケージの復元でvs設定でパッケージをダウンロードすることもできます)。
共有内部ライブラリがある場合は、それらのNuGetパッケージも作成し、そのライブラリのみを含むvsソリューションを作成します。ビルド後のコマンドを追加してnugetパッケージを作成するか、tfsビルドテンプレートを拡張してそれを実行します(すでにこれを行うテンプレートが多数あります)。