version-control - ソース管理でのサードパーティライブラリの保存

Question

アプリケーションが依存するライブラリをソース管理に保存する必要がありますか？私のある部分はそうすべきだと言い、別の部分はそうではないと言います。アプリのいくつかの機能に依存しているという理由だけで、アプリ全体を小さくする20MBのライブラリを追加するのは間違っていると感じます（かなり重くはありますが）。jar / dllだけを保存する必要がありますか、それともプロジェクトの分散zip / tarを保存する必要がありますか？

他の人は何をしますか？

score 51 · Accepted Answer

10年後にプロジェクトを構築するために必要なすべてのものを保存します。万が一の場合に備えて、ライブラリのzipディストリビューション全体を保存します。

2017年の編集：この回答は古くなりませんでした:-)。antやmakeなどの古いものをまだ使用している場合は、上記が引き続き適用されます。依存関係管理でmavenやgraddle（または.net上のNuget）などのより新しいものを使用する場合は、バージョン管理サーバーに加えて、依存関係管理サーバーを実行する必要があります。両方の適切なバックアップがあり、依存関係管理サーバーが古い依存関係を削除しない限り、問題はありません。依存関係管理サーバーの例については、SonatypeNexusやJFrogArtifcatoryなどを参照してください。

score 29 · Accepted Answer

リポジトリにサードパーティのライブラリを含めるだけでなく、ライブラリの将来の更新 (たとえば、セキュリティ修正など) を簡単に追跡してマージできるようにすることをお勧めします。Subversion を使用している場合は、適切なベンダーブランチを使用する価値があります。

サードパーティのコードを変更する前に地獄の寒い日になることがわかっている場合は、（@Matt Sheppardが言ったように）外部は理にかなっていて、切り替えが非常に簡単になるという追加の利点がありますライブラリの最新バージョンは、セキュリティ更新プログラムまたは必須の新機能によって望ましいものになっている必要があります。

また、必要に応じて、コードベースを更新するときに外部をスキップすることもできます。

@Stu Thompson は、ドキュメントなどをソース管理に保存することについて言及しています。大規模なプロジェクトでは、請求書/請求書/議事録/技術仕様などを含む「クライアント」フォルダー全体をソース管理に保存しました。ただし、これらは、他の開発者が利用できるようにするリポジトリとは別のリポジトリに保存することを忘れないでください。クライアント; あなたの「ブラウザソースビュー」...咳... :)

score 21 · Accepted Answer

ライブラリを保存しないでください。それらは厳密に言えばプロジェクトの一部ではなく、リビジョン管理システムのスペースを無駄に占有します。ただし、maven (またはant ビルドの場合はIvy ) を使用して、プロジェクトが使用する外部ライブラリのバージョンを追跡してください。組織内で (バックアップされている) リポジトリのミラーを実行して、常に依存関係を管理できるようにする必要があります。これにより、両方の長所が得られるはずです。プロジェクト外の外部 jar ですが、確実に利用でき、中央からアクセスできます。

score 19 · Accepted Answer

ソースコードをチェックアウトしてビルドスクリプトを実行するだけでプロジェクトをビルドできるようにするため、ライブラリをソース管理に保存します。最新のものを入手して1つのステップでビルドできない場合は、後で問題が発生するだけです。

score 13 · Accepted Answer

サードパーティのバイナリをソース管理に保存しないでください。ソース管理システムは、同時ファイル共有、並行作業、マージ作業、および変更履歴をサポートするプラットフォームです。ソース管理は、バイナリの FTP サイトではありません。サードパーティのアセンブリはソースコードではありません。SDLC ごとにおそらく 2 回変更されます。ワークスペースを完全に消去し、ソース管理からすべてを取得してビルドできるようにしたいという願望は、サードパーティのアセンブリをソース管理に閉じ込める必要があるという意味ではありません。ビルドスクリプトを使用して、配布サーバーからのサードパーティ製アセンブリのプルを制御できます。アプリケーションのどのブランチ/バージョンが特定のサードパーティコンポーネントを使用するかを制御することに不安がある場合は、ビルドスクリプトを使用して制御することもできます。人々は Maven for Java について言及しており、MSBuild for .Net でも同様のことができます。

score 8 · Accepted Answer

通常はリポジトリに保管していますが、サイズを抑えたいというご要望には同感です。

それらをリポジトリに保存しない場合は、何らかの形でアーカイブしてバージョン管理する必要があり、ビルドシステムはそれらを取得する方法を知る必要があります。Java の世界では、依存関係を自動的にフェッチするために Maven を使用している人が多いようですが、私は I を使用したことがないので、賛成も反対もできません。

良い選択肢の 1 つは、サードパーティシステムの別のリポジトリを保持することです。Subversion を使用している場合は、Subversion の外部サポートを使用して、他のリポジトリからライブラリを自動的にチェックアウトできます。それ以外の場合は、ビルドシステムが要件を自動的に取得できる内部匿名 FTP (または同様の) サーバーを保持することをお勧めします。明らかに、古いバージョンのライブラリをすべて保持し、そこにあるすべてのものをリポジトリと一緒にバックアップする必要があります。

score 5 · Accepted Answer

私が持っているのは、すべてのサードパーティライブラリ (ライブラリだけでなく、ドキュメント、Javadoc、およびすべてを含むそれぞれのソース配布) が格納されているイントラネットの Maven のようなリポジトリです。理由は次のとおりです。

変更されないファイルを、変更されるファイルを管理するために特別に設計されたシステムに保存するのはなぜですか?
チェックアウトを劇的に短縮します
ソース管理下に保存されている「something.jar」を見るたびに、「それはどのバージョンですか?」と尋ねます。

score 4 · Accepted Answer

私の好みは、サードパーティのライブラリをSubversionに保持するのではなく、依存関係リポジトリ（ Artifactory with Mavenなど）に格納することです。

サードパーティのライブラリはソースコードのように管理またはバージョン管理されていないため、それらを混在させることはあまり意味がありません。また、リモート開発者は、任意の数の公開リポジトリからより簡単に入手できる場合、低速のWPNリンクを介して大規模なライブラリをダウンロードする必要がないことを高く評価しています。

score 4 · Accepted Answer

JDKとIDE以外のすべてをソース管理に入れました。

トニーの哲学は健全です。データベース作成スクリプトとデータ構造更新スクリプトを忘れないでください。ウィキが出る前は、ドキュメントをソース管理に保存することさえありました。

score 2 · Accepted Answer

以前の雇用主では、アプリケーションをビルドするために必要なすべてをソース管理に保管していました。新しいビルドマシンを起動するには、ソース管理と同期し、必要なソフトウェアをインストールするだけでした。

score 1 · Accepted Answer

サードパーティのライブラリをソース管理に保存して、コードを新しい開発環境にチェックアウトした場合に利用できるようにします。ビルドスクリプトに含まれる可能性のある「インクルード」またはビルドコマンドも、これらの「ローカル」コピーを参照する必要があります。

依存しているサードパーティのコードまたはライブラリを常に利用できるようにするだけでなく、新しい開発者がチームに参加したときに、コードを（ほぼ）新しいPCまたはユーザーアカウントでビルドする準備ができていることも意味します。

score 1 · Accepted Answer

ライブラリを保存してください！リポジトリは、いつでもプロジェクトを構築するために必要なもののスナップショットである必要があります。プロジェクトには異なるバージョンの外部ライブラリが必要なため、これらのライブラリの新しいバージョンを更新/チェックインする必要があります。そうすれば、古いリリースなどにパッチを適用する必要がある場合に、古いスナップショットに対応するすべての正しいバージョンを取得できます。

score 1 · Accepted Answer

個人的には、プロジェクトの一部として依存関係フォルダーがあり、そこに参照ライブラリを保存しています。

多くの場合、同じバージョンのライブラリを必要とする相互に依存する部分があるため、特定のライブラリの最新バージョンに更新することが常に実行可能であるとは限りません。

各プロジェクトのコンパイル時にすべての依存関係を使用するということは、物事が進んだ数年後でも、他の部分を壊すことを心配することなく、プロジェクトの任意の部分を構築できることを意味します。ライブラリの新しいバージョンへのアップグレードは、単にファイルを置き換えて関連コンポーネントを再構築するだけであり、必要に応じて管理するのはそれほど難しくありません。

そうは言っても、私が参照するライブラリのほとんどは比較的小さく、重量が約数百キロバイトであり、それより大きくなることはめったにないため、ソース管理にそれらを貼り付けるだけの問題は少なくなります。

score 1 · Accepted Answer

git サブプロジェクトを使用し、サードパーティライブラリのメイン git リポジトリから参照するか、必要なライブラリごとに新しい git リポジトリを作成します (存在しない場合)。git リポジトリを 1 つだけに制限する理由はありません。また、他の誰かのプロジェクトを自分のディレクトリとして使用することはお勧めしません。

score 0 · Accepted Answer

プロジェクトをビルドするために必要なすべてを保存して、何もせずにチェックアウトしてビルドできるようにします。

（そして、苦痛を経験した人として-コントロールをインストールして開発プラットフォームで動作させるために必要なすべてのコピーを保管してください。私はかつてビルドできるプロジェクトを手に入れました-しかし、インストールファイルとレジストリキーがなければ、できませんでしたサードパーティ製のコントロールレイアウトを変更しないでください。楽しい書き直しでした)

score 0 · Accepted Answer

プロジェクトをビルドするために必要なものはすべて保存する必要があります。さらに、コードのバージョンが異なれば、サードパーティへの依存関係も異なる場合があります。サードパーティの依存関係と共に、コードをメンテナンスバージョンに分岐する必要があります...

score 0 · Accepted Answer

個人的に私が行ってこれまでのところ気に入っているのは、ライブラリを別のリポジトリに保存し、Subversion svn:externals 機能を使用して、他のリポジトリで必要な各ライブラリにリンクすることです。ほとんどのライブラリ (主にマネージ .NET アセンブリ) のバージョン管理されたコピーをソース管理に保持できるため、メインのソースコードリポジトリのサイズがまったく大きくなりません。この方法でアセンブリをリポジトリに格納すると、ビルドサーバーがビルドを行うためにアセンブリをインストールする必要がなくなります。Visual Studio がインストールされていない状態でビルドを成功させるのは非常に面倒でしたが、今では機能するようになったので満足しています。

現在、多くの商用サードパーティ製コントロールスイートなどをあまり使用していないため、ビルドサーバーに SDK を実際にインストールする必要があるライセンスの問題に遭遇していないことに注意してください。問題になりやすい。残念ながら、私にはその解決策がありません。最初に遭遇したときに対処する予定です。

version-control - ソース管理でのサードパーティライブラリの保存

17 に答える 17

Related

Reference