2

複数のプロジェクトで再利用される可能性のある社内の.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を使用するのは非常に苦痛なので、これを破棄しました。そうでなければ、これが私の好ましい解決策になります。
  • svn：externalsを使用して依存関係を解決します。私は2つの理由でこれが好きではありません：
    • （上記のソリューションのように）バイナリファイルのみを処理する代わりに、svn：externalsはソースコードを処理するように強制します。ライブラリとそのソースコードを使用するすべてのプロジェクトを乱雑にしたくありません。
    • どういうわけか、SVN（少なくとも私の意見ではバージョン管理に使用する必要があります）を使用して依存関係を管理することは正しくないと感じています。また、svn：externalsを使用すると、特定のプロジェクトの依存関係を追跡するのが難しくなり、プロジェクトがSVNに依存しすぎるようになると思います。

誰かが私の好みの解決策に関する潜在的な問題や、あなたがそれについて間違っていると思うことを指摘してくれたら本当にありがたいです。また、私が車輪の再発明を試みていて、誰もが使用しているこれに対する標準化された解決策がすでにある場合（私が言及した代替案を除く）、遠慮なく私に教えてください:)

どうもありがとうございます！

4

1 に答える 1

2

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

これにより、個々のプロジェクトの準備が整う前に、個々のプロジェクトに変更を強制することなく、共有ライブラリを変更および変更することができます。プロジェクトは、準備ができたときに最新バージョンを取得し、変更に満足したら新しいバイナリをソース管理にチェックインすることで、準備ができた速度でそれらを受け入れることができます。

于 2012-03-19T15:43:47.470 に答える