私はTFSに比較的慣れていないので、他の人が多くのプロジェクトがあるTFSの組織化に取り組んでいるのではないかと思います。たとえば、TFSプロジェクトをフォルダ内に配置できるかどうか、またはプレフィックス/サフィックスを使用できるかどうかを誰かが知っていますか?
3 に答える
プロジェクトの編成は依然として大部分が主観的ですが、TeamFoundationServerを開始するときに私たち全員が苦労していることです。ALMのドキュメントは役に立ちます。実際には、私が利用することをお勧めするドキュメントの新しいバージョンがあります。VisualStudioTFSブランチガイド2010のCodePlexから入手できます。分岐を計画していなくても、必要な場合に備えて、分岐できる立場にあることは常に賢明な考えです。
以前のガイドとこの新しいガイドを使用してください。私はボイラープレートとして使用する構造を持っています。「メイン」ブランチを含む構造を示します。ブランチを使用している場合は、「メイン」の下のすべてが、必要に応じてそれぞれに複製されることを理解できます。
$/Team Project Root
/Main
/Documentation
/Project A
{XML Help support - such as Sandcastle projects}
/Project B
{XML Help support - such as Sandcastle projects}
/References
{3rd party and scripts to install any the GAC, as/if needed}
/Source
/Project A
{Project file, and associated source}
/Project B
{Project file, and associated source}
/Tests
/Project A
{Project file, and associated source}
/Project B
{Project file, and associated source}
{Solution Files}
これは私たちに役立ち、ガイドラインとなることを目的としています。物事が変化し、組織内でシステムをますます使用するにつれて、ニーズも変化する可能性があることを受け入れる準備ができている必要があります。Mainの下にある各トップレベルフォルダに簡単に取り組みましょう。
ドキュメント-私はSandcastleHelpFile Builderを頻繁に使用する傾向があり、ソースやテストのように、ドキュメントプロジェクトを階層内の独自のレベルに昇格させてきました。
参考資料-アセンブリがTeamFoundationServerの内部に属しているかどうかについて、人々が議論の両側に熱心に取り組んでいるのを見てきました。以前は反対でしたが、このフォルダー構造は頻繁に変更されないことがわかりました。関連するプロジェクトは同じ参照をかなりの数共有することが多く、新しい開発者はプロジェクトを立ち上げるために必要なすべてのものを一挙に入手できるはずです。と実行しています。
ソース-かなり自明。関連するプロジェクト。それぞれが独自のフォルダにバケット化されています。フォルダーとプロジェクトは、完全な名前空間によって名前が付けられます。
テスト-ソースフォルダと同じですが、テスト専用のアーティファクトです。通常、ソースの「プロジェクトA」には、名前空間の一部として.Testsが追加された、テストの対応する「プロジェクトA」があります。
私はすべてのソリューションをブランチの下に置いたので、アプリケーションの複数のビューに「ワンストップショッピング」されます。常に1つの「メガソリューション」で作業する必要がなくなることがわかりました。
分岐に関しては、圧倒されないように、必要に応じて追加します。上にリンクされているガイドは、分岐を徐々に導入するという非常に優れた仕事をしており、単純な構造から始めて、需要に応じて構築するという考えに同意します。私たちが使用する構造は、本番プロジェクトでうまく機能します。また、私が個人的なプロジェクトで使用する構造でもあります。
私が最初にTFSを使い始めたとき、パターンとプラクティス:Visual Studio TeamFoundationServerを使用したチーム開発ガイドが役に立ちました。各プロジェクトをトップレベルに配置し、その下にトランク用の別のフォルダーとそのブランチを配置できます。
$/Project1
$/ProjectTrunk
$/ProjectBranch
$/Project2
$/ProjectTrunk
$/ProjectBranch
これは、ガイドにある多くの例のほんの一例です。
.Net名前空間階層を拡張するアプローチを使用して、類似のビジネスエリアを示し、名前空間をフォルダー構造にマップしました。
名前空間:
Company.AreaA.Project1
Company.AreaA.Project2
Company.AreaB.Project3
Company.AreaB.Project4
フォルダー:
$/Company/AreaA/Project1
$/Company/AreaB/Project3
この慣習はプロジェクト内でも継続されます。