これは共通ライブラリを管理するための良いアプローチですか？

Question

複数のプロジェクトによって潜在的に再利用される可能性のある社内の.NETライブラリを管理するための賢明な方法を見つける必要があります。グーグルで数時間問題を考えると、私は次の結論に至りました：

ビルドサーバー（Jenkins）には、私たちが持っている各ライブラリのバージョンごとに別々の仕事があります。ライブラリが正常にビルドされると、ビルド出力（ほとんどの場合、.dllファイル）が共通ネットワークリポジトリにコピーされます。このリポジトリの構造は次のように考えられます。

-libraryA 
    -1.0 
     -libraryA_1.0.dll 
    -1.1 
     -libraryA_1.1.dll 
-libraryB 
    -1.0 
     -libraryB_1.0.dll 

、具体的プロジェクトの依存関係を格納するために使用されるフォルダに、このリポジトリから必要なライブラリをコピーする簡単な.batファイルが付属しますライブラリを使用したい各プロジェクト。次に、このフォルダから依存関係が参照されます。サンプルプロジェクトは次のようになります。

-project 
    -src 
    -dependencies 
     -libraryB 
      -1.0 
       -libraryB_1.0.dll 
    -getDependencies.bat 

getDependencies.batは常にdependenciesフォルダの内容を削除し、リポジトリからライブラリの新しいコピーを取得します。これはJenkinsでプロジェクトをビルドする前に実行されます。 dependenciesフォルダは決してSVNにコミットされません。

私も考えられてきたいくつかの選択肢：

• を代わりに簡単なリポジトリのカスタムNuGetフィードを使用します。私が見つけたように、私たちがまだ使用しているVisual Studio 2008のNuGetを使用するのはquite a painなので、これを破棄しました。それ以外の場合は、これが私の推奨する解決策になります。
• 依存関係を解決するためにsvn：externalsを使用する。
  • svn：externalsは、バイナリファイル（前述の解決策のように）を扱うのではなく、ソースコードを処理しなければなりません。ソースコードでライブラリを使用するプロジェクトごとに混乱させたくありません。
  • どういうわけか、（少なくとも私の意見では、をバージョニングを管理するために使用する必要があり、）SVNを使用して、管理依存関係はは権利を感じることはありません。私はまた、svn：externalsが特定のプロジェクトの依存関係を追跡するのを難しくし、プロジェクトをSVNにあまりにも依存していると考えています。

誰かが私の好み溶液またはあなたはそれが間違っていると思うだけで何もして潜在的な問題を指摘することができれば、私は本当に感謝します。また、私がホイールを再発明しようとしていて、既に誰もが使用している標準化された解決策があるなら（私が言及した選択肢を除いて）、私を啓発するのをためらってください:)

ありがとう！

Answer 1

変更を破棄するには、ライブラリの別バージョンが必要です。新しい機能を追加してバグを修正しても、新しいバージョンは保証されません。また、ライブラリを使用するプロジェクトは、のソースリポジトリで使用しているバイナリのコピーを保持する必要があります。

これにより、個々のプロジェクトに変更を加えずに共有ライブラリを変更して変更することができます。プロジェクトは、準備が整い次第最新バージョンを入手し、変更に満足した時点で新しいバイナリをソース管理にチェックすることで、準備が整った時点でそのプロジェクトを受け入れることができます。