社内で Nuget ポリシーを実装しようとしてきましたが、内部でホストされている TFS で内部プロジェクトに取り組んでいるときに、自動パッケージ復元の真の価値は何なのか疑問に思っていました。
OpenSource プロジェクトで、または外部でホストされたソース管理を使用している場合、外部パッケージをチェックインしないことで多くのディスク容量を節約できることは理解していますが、この利点 (サーバー上のディスク容量を節約すること) を除けば、自動復元を使用する利点は見当たりません。 : 実際には、ビルド マシンがインターネットに接続しないため、いくつかの問題が発生します。その機能を使用するには、ファイアウォール ルールを変更するか、nuget リポジトリのローカル キャッシュを保持します。
ありがとうございました
スティーブンが彼の答えで示したようにパッケージをソース管理から外しておく主な理由は、ソース管理サーバーによって保存され、ソース管理サーバーとの間で転送される必要があるデータの量を減らすことです。明らかに、すべてのハードウェアを制御する会社では、ディスク容量もネットワーク転送も問題になるはずはありませんが、必要がない場合、パッケージを処理するためにディスク容量/時間を無駄にする必要はありません。パッケージ ディレクトリのサイズは、ワークスペースの合計サイズのかなりの割合になる可能性があることに注意してください。私の場合、パッケージ ディレクトリは、TFS を使用する場合 (私の仕事用ワークスペースの場合) にワークスペース全体の 80% ～ 95% を占め、プライベート ワークスペース (git に基づいているため、.gitスペースを占有するディレクトリ)。
Nuget.org でのアクセスの問題を解決する 1 つの方法は、独自のローカル パッケージ リポジトリを用意することです。このローカル パッケージ リポジトリは、ローカルnuget Web サービスまたはサーバー上の単なる共有ディレクトリである可能性があります。リポジトリは会社の LAN 内にあるため、ビルド サーバーがローカルの nuget リポジトリに到達することは大きな問題にはなりません。このアプローチの副次的な利点は、ビルド プロセスが Nuget.org から独立していることです (非常にまれなケースではダウンします)。さらに重要なことは、どのパッケージがビルドに取り込まれるかを正確に把握できることです (それらは承認済みであるため)。ローカル リポジトリのパッケージ)。
私たちにとって、ローカル nuget リポジトリとパッケージ復元オプションを使用するかどうかの決定は、すべての内部ライブラリを nuget パッケージとしてパッケージ化するという決定に依存していました (開発プロセスについては、別の nuget の質問への回答で説明しました)。そのため、これらの内部パッケージを配布するためのローカル パッケージ リポジトリが必要でした。つまり、サードパーティのパッケージをこのリポジトリに追加するのは簡単で、パッケージの復元を使用することは完全に理にかなっています。内部ライブラリを nuget パッケージとしてパッケージ化しない場合は、それらをソリューションおよびコード ファイルと一緒にソース管理に配置します。その場合、サードパーティのライブラリに対して同じことを行うこともできます。
結局、それはすべてトレードオフです。ディスク容量とインフラストラクチャのセットアップの容易さなど。環境に最も適したソリューションを選択してください。
元の NuGet ワークフローは、Packages フォルダーをソース管理にコミットすることでした。その理由は、開発者が NuGet を持っていないときに通常行うことと一致するからです。つまり、
LibまたはExternalDependenciesフォルダーを作成し、バイナリをそこにダンプし、ソース管理にコミットして、他の人がビルドできるようにします。
そのため、プロジェクトが構築される各マシンでパッケージが復元されるため、バイナリ データはソース管理から除外されます。また、Mercurial や Git などの分散型ソース管理システムでは、サーバーだけでなくクライアント マシンでも使用されるディスク容量と帯域幅です。
しかし、ビルド マシンが nuget.org へのインターネットに接続できない場合、問題が発生します (私は推測しています)。私はあなたが主要な解決策を打ったと思います。パッケージをソース管理にコミットし、パッケージの復元を回避するか、ビルド マシンがインターネットに接続できるようにするか、ローカル ミラーをセットアップします。
あなたの環境でパッケージを復元する利点はないとは言いません。パッケージをコミットすることに大きな害はありません。しかし、実際には、チームがどのように機能するか、チームが何を期待しているか、どのタイプのエンタープライズ環境で作業しているかによって異なります。