29

私たちのチームは、Team Foundation Server v.11（2012）を使用してプロジェクトを管理することを検討しています。現在、スプレッドシートでプロジェクト管理を行っています。私たちのチームは内部クライアント専用のソフトウェアを開発しており、プロジェクト間で多くのdll共有があります。ソースコードのバージョン管理にもSVNを使用しています。

共通ライブラリ、アプリケーションライブラリ（ビジネスルールなど）、イントラネットWebサイト、インターネットWebサイト、Windowsフォームなど、アプリケーションのさまざまな部分に対応するソリューションがあります。SVN構造は次のようになります

SVN
    -CommonLibrary (VS Solution)
        -Source
            -CommonLibrary.Core (VS Project)
            -CommonLibrary.Security (VS Project)
            -CommonLibrary.Web (VS Project)
    -OurCompanyLibrary (VS Solution)
        -Libraries (Projects within this solution reference these)
            -CommonLibrary.Core.dll
            -CommonLibrary.Security.dll
        -Source
            -OurCompanyLibrary.Application1 (VS Project)
            -...
            -OurCompanyLibrary.ApplicationN (VS Project)
    -OurCompanyIntranet (VS Solution) (MVC framework)
        -Libraries (Projects within this solution reference these)
            -CommonLibrary.Core.dll
            -CommonLibrary.Security.dll
            -CommonLibrary.Web.dll
            -OurCompanyLibrary.Application1.dll
        -Source
            -OurCompanyIntranet.Application1 (VS Class Library Project)
            -...
            -OurCompanyIntranet.ApplicationN (VS Class Library Project)
            OurCompanyIntranet.UI (VS Web Project)
    -OurCompanyInternet (VS Solution) (MVC framework)
        -Libraries (Projects within this solution reference these)
            -CommonLibrary.Core.dll
            -CommonLibrary.Security.dll
            -CommonLibrary.Web.dll
            -OurCompanyLibrary.Application1.dll
        -Source
            -OurCompanyInternet.Application1 (VS Class Library Project)
            -...
            -OurCompanyInternet.ApplicationN (VS Class Library Project)
            -OurCompanyInternet.UI (VS Web Project)

コードを複数のソリューションに分割する理由は、さまざまな状況（イントラネットアプリ、インターネットアプリ、Winformアプリ）でアプリケーションライブラリを再利用できるためです。また、イントラネットおよびインターネットソリューションには、複数のアプリケーションが含まれています。これが現在の構造です。これが最良の組織構造であるかどうかはわかりませんが、私たちにとってはうまくいきます。

TFSに切り替える際の問題は、1つのチームプロジェクトが複数のVSソリューションにパーツを含めることができないことです。たとえば、Application1のTFSチームプロジェクトを設定して、そのアプリケーションの製品バックログを作成します。Application1では、アプリケーションを完了するためにOurCompanyLibrary、OurCompanyIntranet、およびOurCompanyInternetを変更する必要がありますが、TFSを使用すると、Application1のVSソリューションは1つだけになります。

これは、アプリケーションを開発する方法の例です。OurCompanyLibraryVSソリューションに保存されているすべてのドメインモデルとビジネスルール。アプリケーションを開発するとき、それをApplication1と呼びます。まず、OurCompanyLibraryVSSolutionの下のOurCompanyLibrary.Application1VSプロジェクトでドメインモデルとビジネスルールの作成を開始します。ドメインモデルが開発されたら、OurCompanyIntranetおよびOurCompanyInternetVSソリューションでUI側のプログラミングに移ります。これらのソリューションはMVCスタイルのWebサイトです。OurCompanyIntranetには、すべてのビュー（.aspxファイル）、css、javasciprtなどを含むVS WebプロジェクトOurCompanyIntranet.UIが含まれています。OurCompanyIntranetには、アプリケーション（この場合はOurCompanyIntranet.Application1）で区切られたすべてのモデルとコントローラーも含まれています。これをTFSで整理すると、問題になります。

これをTFSでどのように整理しますか？より意味のあるコード構造を整理する別の方法はありますか？私たちを正しい方向に導くような記事やウェブサイトは大いに役立ちます。

4

4 に答える 4

44

まず、複数のチームプロジェクトを使用しないでください。これは、最初は誰もが犯す大きな間違いです。チームの規模と開発内容については、1つのチームプロジェクトが必要です。

完全に異なる人々の2つのチームがあり、完全に異なる方法論/プロセスで完全に異なるプロジェクトに取り組んでいる場合は、2つのチームプロジェクトを使用します。

1つのチームプロジェクトで、次のことができます。

  • 多くのブランチがあります（関連しているかどうかに関係なく）。
  • 必要な最も小さなレベルでソース管理を管理する
  • 作業項目のエリアパス（ノードツリー）を使用して、プロジェクトをサブカテゴリ（機能、技術、必要なもの）に分割します。このようにして、1つの大きな製品バックログまたは専用のものを使用できます。
  • プロジェクト全体または特定のエリアに関する全体的なレポート（引き続きエリアパスを使用しますが、Reporting Servicesで）
  • それを信じてください。それが最善の方法であり、多くの人（初めて私を含む）が複数のチームプロジェクトを使用するのを間違え、その後は代金を支払わなければなりません。必要なのは、優れたソース管理階層構造と優れたエリアパスツリーです。

ソリューションに関して：

プロジェクトの主要コンポーネントごとに1つのソリューションを用意することは悪いことではありません。開発者は、プロジェクトの専用サブセットに取り組み、生産性を最大化し、コンポーネント間の結合を減らすことができます。

ただし、すべてのプロジェクトを参照し、すべてのプロジェクトに影響を与える変更を加える必要がある場合はいつでも使用できる1つのグローバルソリューションを使用できます。グローバルなソリューションを持つことは、プロジェクト全体を簡単に構築するための簡単な方法でもあります。

ここでの問題はクロスコンポーネント参照に関するものです。開発する1つのコンポーネント（Application1など）が開発する別のコンポーネント（OurCompanyLibraryなど）を必要とする場合、両方の間に依存関係が作成され、Application1はOurCompanyLibraryの「ビルドされたアセンブリ」を参照する必要があります。

これは次のいずれかを意味します。

  1. 他の人が参照するすべてのコンポーネントのビルドされたアセンブリを保存するには、ソース管理のどこかに場所を作成する必要があります。ビルドサイクルを維持して、正しい順序を尊重するすべてのものをリリースします。

  2. Nugetという新しい標準を利用して、社内のNugetサーバーをセットアップし（非常に簡単に実行できます）、他のユーザーが参照するコンポーネント用に独自のNugetパッケージを構築します。

  3. 最も簡単な方法は、社内で開発したすべての依存関係をソリューションに含めて、必要なときに確実に構築されるようにすることです。簡単に実行できますが、Application1プロジェクトにはほとんどのVSプロジェクトが含まれます。私はそれが良い方法でも悪い方法でもありません、それはあなたの呼びかけです。時には簡単な方法が最良の方法です。

それぞれの方法には独自の長所/短所があり、どちらが最適かを決めることができるのはあなただけです。

于 2012-06-12T08:33:55.427 に答える
0

あなたがそれを予測したように：-

OurCompanyLibraryはVSソリューションになります。

OurCompanyLibrary.Application1 ... OurCompanyLibrary.ApplicationNは、そのソリューション内のVSプロジェクトになります。

OurCompanyLibrary.ApplicationX.dllsは、OurCompanyIntranetおよびOurCompanyInternetVSソリューションの参照になります。

私はあなたの問題を理解しているかどうかわかりません。

OurCompanyLibraryのアプリケーションVSプロジェクトは、個別にビルド可能で、他の2つのソリューションで参照できる独自のdllを生成します。問題がすべてのアプリケーションを1つのVSチームプロジェクト（OurCompanyLibrary）の下に置くことである場合、答えは、アプリケーションごとに個別のVSチームプロジェクトを作成することです（Application1の場合はOurCompanyLibrary1、Application2の場合はOurCompanyLibrary2など）。各アプリケーションの開発は次のようになります。完全に自己完結型で、他から分離されています。

問題が、異なるソリューションでソースの異なる部分が必要な場合は、プロジェクトをソリューションに追加することで実現されます。これは、これらのソリューションのすべてにすべてのソースコードがあることを意味します。私が働いている場所にも似たようなものがあります。-共通のビジネスロジック層と共通のデータアクセス層の2つのプロジェクトを持つソリューションがあります。他の各ソリューションには、これらのプロジェクトが含まれています。これは、どのソリューションからでもソースコードを編集できることを意味します。

これがあなたに役立つかどうかはわかりませんが、頑張ってください！

于 2012-06-05T21:08:06.710 に答える
0

これが製品で実行されているアプリケーションである場合、フォルダー/ソリューションの構造に最小限の変更を加えます。ビルド定義のTFSでは、複数のプロジェクトを選択するか、次の例のようにビルドスクリプトに複数のソリューションを配置することもできます

単一のTFSチームビルド定義から2つのソリューションを構築する方法

于 2012-06-07T01:21:52.483 に答える
0

コードベース全体の集中レポートが必要な場合は、1つのTeamProjectを使用してすべてをホストする可能性を検討する必要があります。
次に、異なるコンポーネント/パーツを区別するために、このTeamProject内で別々のエリアを使用できます。この非常に興味深い記事、特に長所/短所のセクションを
チェックしてください。

于 2012-06-12T08:54:12.183 に答える