1

私たちはエンタープライズ ソフトウェアを開発しており、開発者間でコードの再利用を促進したいと考えています (この問題を簡単にするために、すべて .NET と仮定しましょう)。私たちは新しい VCS システム (ほとんどの場合 mercurial) に移行しようとしていますが、ライブラリを共有する方法について戦略を立てたいと考えています。

次の使用例を満たす共有ライブラリを管理するための最適なプロセスは何ですか?

  1. ブラック ボックス - ライブラリのパブリック API のみが知られており、使用する開発者がライブラリに「ステップ イン」またはブレークポイントを設定できるという前提はありません。ライブラリはブラックボックスです。多くの場合、開発者は詳細を気にしません。常に「機能している」ライブラリのバージョンを教えてください。
  2. デバッグ - 開発者は、開発中にライブラリに少なくとも「ステップ イン」できる必要があります。ブレークポイントの設定もおまけです。
  3. 並列開発 - 少数派である可能性が高いですが、使用するアプリケーションと並行してライブラリを開発するための一見有効なユースケースがあります。多くの場合、ライブラリとコンポーネントの作成者は同じ開発者です。良くも悪くも、多くの場合、アプリケーションとライブラリは密結合になっています。両方に変更を加えてデバッグできることは、私たちが開発するための非常に生産的な方法です。

3 を解くと 2 が暗黙のうちに解かれる可能性があることに注意してください。

ソリューションには、追加のツール (NuGet など) が含まれる場合があります。

4

2 に答える 2

1

ライブラリを共有することにより、次のものを区別する必要があります。

  • ソースの依存関係 (ソースを共有しており、プロジェクト内での再コンパイルを暗示しています)
  • バイナリの依存関係 (共通のソースからコンパイルされた配信を共有します) とプロジェクトからのリンク。

両方に関して、NuGet (2.0) は最終的に「ビルド中のパッケージの復元」を導入し、ビルドやフォルダーが何であれソース管理にコミットしないようにしました。LibExternalDependencies

NuGet (特に新しい階層構成である NuGet 2.1) は、C# プロジェクト内でのモジュール管理に適しており、git と Mercurial の両方と連携します。

それをMercurial サブリポジトリと組み合わせると、再利用したい共通のコード ベースを独自のリポジトリに分離できるはずです。

于 2012-10-25T11:37:30.097 に答える
1

この問題には2つの可能な解決策がありますが、どちらも理想的ではないようです(したがって、質問を投稿した理由)。

  1. VCS を使用して依存関係を管理します。具体的には、Mercurial サブリポジトリを使用し、常にソースごとに共有します。
    • 利点:
      1. 3 つのユースケースがすべて解決されます。
      2. ソース管理と依存関係管理に必要なツールは 1 つだけです
    • 短所:
      1. Subrepos 機能は、Mercurial 開発者による最後の手段の機能と見なされており、実験と読み取りから、次の問題があります。
        • タグは、複数のリポジトリに簡単またはアトミックに適用することはできません。
        • ルート/シェル リポジトリは本質的に脆弱です (サブリポジトリへのパスが変更されると破損する可能性があります)。Mercurial の開発者は、シェル リポジトリにコンテンツを含めず、サブリポジトリの定義 (およびリビジョンの追跡) にのみ使用することで、この問題を軽減することを提案しています。そのため、サブレポのパスが壊れていても、開発者は手動で瞬間を再作成できます。
        • 分岐はレポの境界を越えることはできません (分岐は特定のサブレポでのみ発生する必要があると主張する可能性があるため、おそらく大きな問題ではありません)。
  2. IvyまたはNuGetを使用して依存関係を管理します。これには 2 つの方法があります。
    1. 依存関係/パッケージには、単に公式のバイナリを含めることができます。開発者が新しいバージョンのビルドを送信したときに、新しい依存関係/パッケージを会社のリポジトリに発行するようにビルド サーバーを構成できます。これにより、ケース 1 が解決されます。Nuget は、ケース 2 を解決する可能性のあるシンボル パッケージをサポートしているようです。ケース 3 は解決されず、そのケースの開発者は乾かして独自のソリューションを考え出すことになります (アプリケーションを VCS にコミットする方法は基本的にありません)ソースごとの依存関係を含む)。これは、依存関係管理ツールが使用される従来の方法のようです。
    2. 依存関係/パッケージには、mercurial からソースを取得するスクリプトを含めることができます。依存関係/パッケージがインストールされると、スクリプトが自動的に実行される可能性があります。(ファイルシステムを参照するのではなく) プロジェクトごとの参照を .NET ソリューションに含めるために、いくつかの魔法が実行されますが、理論的には、これは NuGetインストール スクリプトで発生し、アンインストール スクリプトで逆になる可能性があります。
      • 「ソース」と「バイナリ」の依存関係の切り替えは、手動のステップのようです。開発者はリリースのバイナリ依存関係に切り替える必要があり、おそらくこれはリリースを作成するときにビルド サーバーで強制される可能性があると私は主張します。これは、プロジェクトとバイナリを参照するように VS ソリューションを変更する必要があるという事実によってさらに複雑になります。
      • ソースパッケージはいくつありますか? すべてのバイナリ パッケージには、ビルドに使用したソースを取得するためのスクリプトが含まれていますか? それとも、インストール スクリプト マジックを使用してソースを取得する別のソース パッケージを作成しますか? これは、Mercurial のすべてのタグのソース パッケージがあるかという疑問につながります。すべてのチェンジセット？または、単純に 1 つのソース パッケージを複製してチップに更新し、開発者に前のリビジョンへの更新を任せます (ただし、これにより、どのリビジョンに更新するかを知るという問題が生じます)。
      • 開発者が mercurial を使用してソースのリビジョンを変更した場合、これを消費するアプリケーションにどのように反映させることができますか? ソースの取得に使用された依存関係/パッケージは変更されていませんが、ソース自体は...
于 2012-10-25T11:40:06.350 に答える