2

大規模なプロジェクトが複数のプロジェクトに分割され、それぞれが個別の Mercurial リポジトリに格納されているとします (Mercurialで共有依存関係を持つプロジェクトを編成する良い方法は何ですか?に従って)。

また、依存関係マネージャーが内部で使用されているとします (ここでは NuGet を使用していますが、Maven にも同じことが当てはまります)。

  • ProjectA は Ninject と MongoDB に依存しています
  • ProjectB は ProjectA に依存し、log4net

プロジェクト A と B は個別にビルドできます。NuGet は、NuGet サーバー (この場合は ProGet) から OSS と内部の依存関係の両方を自動的にダウンロードします。

最後に、ProjectB が ProjectA の v1.2.3.4-SNAPSHOT に依存し、CI サーバーが NuGet サーバーの ProjectA.1.2.3.4-SNAPSHOT パッケージを継続的に更新するとします。これにより、ProjectB は常に ProjectA の最新のチェックイン変更に対して開発されます。

プロジェクト A と B の両方で関連する変更が必要な場合はどうなりますか? これを適切に行うには、どのような巧妙で巧妙な方法がありますか? いくつかのアイデア:

  • 開発者はプロジェクト A と B をチェックアウトします。A に変更が加えられ、ビルドされ、チェックインされます。開発者は、CI サーバーが NuGet サーバーをビルドして更新するのを待ちます。B に変更を加え、ビルドし、チェックインします (コードは開発プロセスの一部としてチェックインされるため、これは嫌いです)。
  • 開発者はプロジェクト A と B をチェックアウトし、(NuGet パッケージ ProjectA の代わりに) A ソースを依存関係として使用するように B を再配線します。変更は A と B の両方に対して行われます。適切なテストの後、A と B の両方に対してチェックインが実行されますが、開発者は依存関係の変更がチェックインされていないことを確認する必要があります。

私はこれが特に得意ではないので、誰かが私のアイデアを非常に巧妙な方法で水中から吹き飛ばしてくれると思います。

4

2 に答える 2

0

nugetを使用すると、次のことが考えられます。プロジェクトAでは、パッケージを中央の場所にドロップします（この例では、c：\ localpackagesに配置しています）


MSBUILD.exe / t：Build、PackageA.csprojを使用してビルドA

プロジェクトBでは、指定する.nuget \ nuget.configを追加できます（パッケージフォルダーの場所の指定について詳しくは、 http：//docs.nuget.org/docs/release-notes/nuget-2.1を参照してください）。プロジェクトAによって行われた変更。A用に異なるバージョンのnugetパッケージをドロップすると、注意が必要になる場合があります。

お役に立てれば。

于 2012-10-12T04:46:11.490 に答える
0

NuGetがどのようにそれを行うかはわかりませんが、Mavenを使用すると、「Bを再配線してAソースを依存関係として使用する」ことを除けば、2番目のアイデアはうまく機能します。A をローカルで ( を使用して) ビルドするだけでinstall、ローカルの Maven リポジトリにインストールされます。次に、B をビルドするときに、中央リポジトリからのものではなく、新しくビルドされた A を取得します。

于 2012-08-02T08:14:02.687 に答える