これは以前に尋ねられたかもしれませんが、以前のすべての投稿で私のニーズに対応できませんでした (数時間検索していました)。すべての投稿は、その特別なニーズに非常に固有です。（私は数年間プロジェクトを書いていますが、TFSの初心者です）
私の必要性: デフォルト コレクションの下に共通のヘルパー プロジェクトが 1 つあります。（すべてを書き直すのを避けるのに役立つ単純なヘルパークラスと関数）
さまざまなコレクションのすべての tfs プロジェクトでこのヘルパー プロジェクトを使用しようとしています。
使用するのに最適なシナリオは何ですか?
デフォルト コレクション -- HelperProj
コレクション 1 -- プロジェクト 1 -- プロジェクト 2
コレクション 2 -- プロジェクト 3 -- プロジェクト 4
よろしくお願いします
やむを得ない理由がない限り、1 つのコレクションで 1 つのプロジェクトを使用することをお勧めします。
その理由は、TFS は多くの点で 1 つの大きなファイル システムのように見えますが、プロジェクトやコレクションの境界を越えてうまく機能しないものがあるからです。私の経験では、コードをさまざまなプロジェクト/コレクションに配置しても、コードの塊の間に依存関係がない (そして今後も存在しない) 場合にのみ正常に機能するため、単一のプロジェクト/コレクションを分離して作業できます。
私たちの会社は、「実際の」プロジェクトごとに TFS プロジェクトから始めましたが、ドキュメント、アセット、およびコードの 3 つのプロジェクトを含む 1 つのコレクションにコードベース全体を再編成するまで、常に問題に直面していました。相互依存性なし)
プロジェクト内でもコードをフォルダーに整理できるため、コードベースごとにアクセス/セキュリティ要件が大きく異なる場合を除き (依存関係がない場合はほとんどありません)、IMO では、異なるプロジェクトやコレクションを使用しても意味がありません。
もう 1 つのアプローチは、説明した 3 つのコレクションを使用することですが、DefaultCollection でライブラリを事前にビルドして、他のコレクションのコードからリンクできるバイナリの共有リポジトリを提供することにより、それらの間の「ライブ」依存関係を排除します。これは、ライブラリ コードを更新できても、バイナリが他のコレクションの 1 つにすぐにマージされないバージョン管理にも役立ちます。これにより、他のコレクションに取り組んでいるチームは、適切な場合にのみライブラリ コードの更新を取り込むことができます。これにより、チーム A の変更がチーム B によってすぐに使用されることによって引き起こされる問題を防ぐことができます。