2

独自に開発したコード ライブラリを使用する際の適切なリリース管理に関する情報を探しています。私たちは Visual Studio 2010 で作業しており、.NET で開発し、TFS を使用しています。状況をスケッチしましょう。

私たちはチームと協力してさまざまなプロジェクトに取り組んでおり、その結果すべてが独自のプログラム/製品になります。そこで、コードを再利用して、一種のフレームワークやライブラリに入れることを考え始めました。このために、異なるプロジェクトとそれらの間の依存関係を持つ別のソリューションを作成しました。これを「プラットフォーム」と呼びます。

「プラットフォーム」のソリューションには、たとえば次のプロジェクトがあります。

  • ロギング
  • Logging.Tests
  • ユーティリティ
  • チャートコントロール
    • ロギングの依存関係
    • ユーティリティの依存関係
  • ローカリゼーション
    • ロギングの依存関係
  • ローカリゼーション.テスト

実際には、すでに 20 のプロジェクトがあり、プロジェクト間の依存関係はさらに多くなっていますが、これで状況が明確になるはずです。

2 つのプロジェクトAとBがあるとします。それらは次のようになります。

プロジェクトA

  • ロギングへの参照
  • ユーティリティへの参照
  • ChartControl への参照
  • ローカリゼーションへの参照
  • ダル
    • ロギングの依存関係
  • メインアプリ
    • DAL の依存関係
    • ロギングの依存関係
    • ユーティリティの依存関係
    • ChartControl の依存関係
    • ローカリゼーションの依存関係

プロジェクトB

  • ChartControl への参照
  • ローカリゼーションへの参照
  • メインアプリ
    • ChartControl の依存関係
    • ローカリゼーションの依存関係

この種の構造をどのように管理しますか？私はいくつかの問題を見ていますが、それらに対する本当の答えはありません。

  • プラットフォームのプロジェクト A と B に DLL またはコードを含めますか?
  • DLL をチェックインして、別のプロジェクトにコピーを作成しますか? 分岐は有益でしょうか?
  • バージョンはどうですか？プロジェクト A が Logging V.1.0.0.0 を使用していて、Logging V.1.0.0.0 も使用している ChartControl で問題なく動作するとします。ある日、新しいバージョンの Logging V.2.0.0.0 も使用する ChartControl の新しいバージョンを使用することにしました。プロジェクト A が Logging V.2.0.0.0 の使用も強制されないようにするにはどうすればよいですか?
  • プラットフォームを一部としてリリースするか、すべてをリリースするか、まったくリリースしないかを決めることができました。しかし、これらすべての DLL のビルドをどのように管理すればよいでしょうか。すべてのプロジェクトのバージョン番号を手動で更新するのは大変な作業であり、すべての異なる bin フォルダーからバージョン番号を抽出するのはさらに大変です。
  • プロジェクトに「プラットフォーム」をどのように統合しますか。参照フォルダーを作成し、そこにすべての DLL を配置して、ソリューションでそれらを参照しますか?
  • 依存関係を追跡するにはどうすればよいですか? また、プラットフォーム全体で 1 つのリリースを行う場合、不要な DLL をどのように廃棄すればよいでしょうか。たとえば、プロジェクト B は Utils には関心がありませんが、間接的に Logging には関心があります。
  • プラットフォームを 1 つとしてリリースすると、わずかな変更で完全に新しい DLL のセットが作成されます。たとえば、Utils プロジェクトを変更すると、変更がない限り、ロギング、ローカリゼーションなどの新しいバージョンも作成されます。

私もインターネットを検索しようとしましたが、社内で議論しましたが、実際の答えはどこにもありませんでした。私が Stack Overflow で見つけたのは、ライブラリとフレームワークの定義の違いに関するもので、MSDN では DLL と GAC についてたくさん読むことができます。

ベスト プラクティス、ツール、経験などは大歓迎です。

4

2 に答える 2

1

「プラットフォーム」用の NuGet パッケージを作成し、それらを明確な依存関係構造を持つ論理ブロックに分けて、たとえば「Utils」が必要なときにこのパッケージをインストールすると、「Logging」パッケージがすぐにインストールされるようにします。また、バージョン管理についても説明します。

http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-packageを参照してください

次に、これは内部フレームワークであるため、独自の NuGet フィードのセットアップを検討する必要があります: http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds

これを設定するのは最初の取り組みかもしれませんが、長期的には、このアプローチのメリットを確実に享受できます。

于 2012-08-23T11:04:58.747 に答える
0

すべてのコードを含む階層ディレクトリ構造を使用し、ライブラリDLLのバージョンをリリースします。相対パスを使用して、他のDLLまたはプロジェクトを参照します。これにより、必要に応じて依存関係を維持および更新する柔軟性が得られます。

プラットフォームのプロジェクトAとBにDLLまたはコードを含めますか？

すべてをTFSにチェックインします。各プロジェクトは、DLLまたはプロジェクトファイルを参照して、依存関係を解決するかどうかを決定できます。

DLLをチェックインして、さまざまなプロジェクトにコピーしますか？分岐は有益ですか？

DLLをチェックインしますが、ソース管理構造の低レベルの共有リソースフォルダーに保持します。

/Shared
    /DLLs
        /Platform
            /Logging
                /V1.0.0.0
                    /Debug
                    /Release
                /V2.0.0.0
            /ChartControl
/Source
    /Platform
        /Logging
        /ChartControl
    /Projects
        /ProjectA
        /ProjectB

バージョンはどうですか？プロジェクトAがLoggingV.1.0.0.0を使用し、LoggingV.1.0.0.0も使用するChartControlで正常に機能するとします。ある日、新しいバージョンのChartControlを使用することにしました。これも新しいバージョンのLoggingV.2.0.0.0を使用しています。プロジェクトAがLoggingV.2.0.0.0の使用を強制されないようにするにはどうすればよいですか？

異なるプロジェクトで同じライブラリの異なるバージョンを参照する必要がある場合は、各リリースバージョンをチェックインしてください。したがって、 ChartControlは/Shared/DLLs/Logging/V1.0.0.0を参照できますが、ProjectAはV2.0.0.0を参照できます。（ただし、これは厄介になる可能性があるため、注意する傾向があります。新しいロギングバージョンが異なるファイル/データベース形式を使用している場合はどうなりますか？）

プラットフォームを一部としてリリースするか、すべてをリリースするか、まったくリリースしないかを決めることができます。しかし、これらすべてのDLLのビルドをどのように管理するのでしょうか。すべてのプロジェクトのバージョン番号を手動で更新するのは大変な作業であり、すべての異なるbinフォルダーからそれらをさらに抽出します。

ビルドタスクを自動化するには、継続的インテグレーションサーバー（Cruise Control、QuickBuild、Jenkinsなど）を確実に調べてください。

「プラットフォーム」をプロジェクトに統合するにはどうすればよいですか。ソリューションでそれらを参照するために、参照フォルダーを作成し、そこにすべてのDLLを配置しますか？

これが正しいアプローチだと思います。DLLを参照すると、プラットフォームの個別の開発/テスト/リリースプロセスに準拠できます。

依存関係を追跡するにはどうすればよいですか？また、プラットフォーム全体の1つのリリースの場合、不要なDLLをどのように破棄しますか。プロジェクトBは、たとえばUtilsには関心がありませんが、間接的にLoggingに関心があります。

各プロジェクト所有者は、独自の依存関係を追跡する必要があります。プロジェクトBの所有者だけが、Utilsを参照するかどうかを知っています。

プラットフォームを1つとしてリリースすると、小さな変更により、完全に新しいDLLのセットが作成されます。たとえば、Utilsプロジェクトを変更すると、変更がない限り、ロギング、ローカリゼーションなどの新しいバージョンも作成されます。

これは大丈夫ですよね？それは政策の問題です。各プロジェクトがプラットフォームの最新リリースを統合することを余儀なくされた場合、または古いバージョンに対して機能することは問題ありません。あなたは後者が真実であることを示唆していると思います。プロジェクトA、Bなどは最終製品であるため、新しいDLLをいつ統合するかは、これらのプロジェクトの所有者が決定します。

于 2012-08-21T16:47:32.823 に答える