ここには 2 つの選択肢があります。
- 組織内でNuGet ギャラリーのインスタンスを実行します。これはnuget.orgを実行するコードです
- Nuget サポートが組み込まれており、Nuget リポジトリとして機能するArtifactory Proのライセンスを取得します。
私は両方を使用しましたが、最初は #1 を選択するのが合理的ですが、NuGet ギャレーは、オンプレミス/エンタープライズでの使用ではなく、nuget.org 向けに最適化および設計されているため、パッケージの削除などは面倒です (手巻きの SQL が必要です)。 ）。
Artifactory Pro の (低い) ライセンス料を支払うべきだと思います。これは優れた製品であり、JFrog チームは非常に熱心で、熱心です。
内部/エンタープライズ パッケージには nuget.org を使用しないでください。nuget.org は、内部ビルドの依存関係ではなく、サード パーティ/オープン ソース ライブラリ用に設計されています。
編集:ワークフローに関して、共有コードを複数のパッケージに入れるのはなぜですか? コードを共有する必要がある場合は、独自の別のパッケージに入れる必要があります。
編集 2 : 開発者のコード変更ワークフローを高速化するには、nuget.exe(コマンドライン クライアント) を使用してコマンドラインからアクセス可能なビルドを使用できるため、「開発者」ビルドの実行をターゲットにできます。次に、(CI ビルドではなく) "開発者" ビルドでnuget install B -Source C:\Code\B、新しく更新さBれたものを依存関係としてプルし、それに対してビルドする場合は、-Source をローカル パス (例: ) として指定します。Cまたは他のローカルの新しく更新されたパッケージについても同様です。次に、A、B、およびCすべてが正常にビルドされたらgit push、それらすべてを (逆の依存関係の順序で) CI に任せることができます。
ただし、このビルド「ダンス」を頻繁に行う必要がある場合は、パッケージの分離が本当に適切かどうかについても質問する必要があります。これは、すべてのコードを単一のパッケージにするか、別のパッケージの異なる行に沿って分割する必要があることを示唆しているためです。適切に定義されたパッケージの重要な機能は、セマンティック バージョニングを効果的に使用している場合はもちろん、他のパッケージに波及効果を引き起こさないことです。
編集 3 marcelo-oliveira によって要求されたいくつかの明確化: 「コマンド ラインでアクセス可能なビルド」は、通常はバッチ ファイルを介して、Visual Studio を使用せずにコマンド ラインから完全に実行できるビルドです。「開発者ビルド」は、CI サーバー上で実行される CI ビルドとは対照的に、開発者が自分のワークステーションから実行するビルドです (どちらのビルドも本質的に同じである必要があります)。