当社では、開発プロセスに Team Foundation Server 2010 の使用を開始することにしました。
コレクションとチーム プロジェクトをどのように構成するかを決めるのに苦労しています。
合計 9 人の開発者がいて、全員が異なる時期に異なるプロジェクトに取り組んでいます。
私が読んだものの半分は、必要な数のコレクションを使用するように言っているようですが、残りの半分はコレクションの数を制限するように言っています。
必ずしも相互に作用しない複数のプロジェクトを作成/管理する場合、どのようなアプローチをとっていますか? 別々のコレクションに入れるのが最善ですか、それともコレクションの数を少なくしておくのが賢明ですか? どんな助けでも大歓迎です。
個人的には、ここにたくさんのコレクションを置いて水を濁すつもりはありません。開発者が作業するそれぞれのチーム プロジェクトを含む既定のコレクションは問題ありません。
各「デフォルト コレクション」は、(同じ環境内で実行されている) TFS の個別のインスタンスのようなものです。コレクションは互いに交差せず、すべてのデータは常に別々に保たれるという考え方です。私の記憶が正しければ (まだ TFS 2008 を使用しているため、今はテストできません)、実際には、あるコレクションから別のコレクションに切り替えて、そのコレクションで作業を開始する必要があります。2 つのコレクションを同時に開くことはできないと思います。
この質問に対する私の基本的な答えは、チーム プロジェクトはプロジェクトのライフサイクルを反映する必要があるということです。たとえば、顧客がいて、顧客のためにプロジェクトを行う場合、顧客のプロジェクトごとにチーム プロジェクトを作成します...別のプロジェクトと同じソース コードが含まれていても.
社内開発の場合、特定のアプリケーションのライフサイクルは通常「永続的」であるため、基幹業務アプリケーションごとにチーム プロジェクトを使用することがわかります。
あなたのような小規模なショップが追加のプロジェクト コレクションを作成する唯一の理由は、そのレベルの分離が必要な場合です。いくつかの理由は次のとおりです。 1. ソース コードを保持し、作業を分離するための法的または規制上の理由がある (政府、プライバシー、PCI など)。2. プロジェクトの最後に作業項目とコードを提供することを希望する顧客がいます。他のユーザーのデータを並べ替える代わりに、自分のプロジェクト コレクションを簡単に提供できるように、履歴が必要な場合もあります。
さらに情報が必要な場合は、プロジェクトの性質を投稿すると役立つ場合があります。
コレクションごとに個別のビルド サーバー (およびライセンス) が必要になるため、計画ではそれを考慮する必要があります。1 つのビルド サーバー、1 つのコレクション。