web-dev-qa-db-ja.com

従来のn層設計で複数のプロジェクトを使用するGitリポジトリのベストプラクティス

一元化されたSCMシステムからGITに切り替えています。 OK、どちらかを認めます。それはVisualSourceSafeです。したがって、Gitコマンドとワークフローの学習曲線を乗り越えることに加えて、私が現在直面している最大の問題は、単一または複数のリポジトリのいくつかのフレーバーに関して、現在のリポジトリをGitに移行する方法です。

この質問はさまざまな方法で尋ねられますが、通常は基本的なものです...「低レベルのライブラリを共有したいアプリケーションがあります」と返信定型文は常に「個別のリポジトリを使用する」および/または「使用する」です。このパターンをいつ/なぜ使用する必要があるのか​​（何を克服するのか、何を排除するのか）についての説明があまりない「Gitサブモジュール」特にGitを初めて使用する人にとっては。

ただし、誰かが露骨に尋ねるのはまだ見たことがありません。「各レイヤーが独自のプロジェクトである従来のn層開発（UI、ビジネス、データ、共有ツール）がある場合、1つまたは複数を使用する必要があります。リポジトリ？」 ほとんどの場合、新しい「機能」が追加されると、コードの変更が各レイヤーに波及しますであるため、私にはわかりません。

Gitに関する問題を複雑にするために、これらのレイヤーを「フレームワーク」全体に複製して、開発者の観点からより管理しやすいプロジェクト/コンポーネントを作成しました。この議論の目的のために、これらのプロジェクト/レイヤーのコレクションを「タヒチ」と呼びましょう。これは「製品」全体を表します。

私たちのセットアップの最後の「レイヤー」は、タヒチをカスタマイズ/拡張するクライアントのウェブサイト/プロジェクトの追加です。これをフォルダ構造で表すと、次のようになります。

/Clients
  /Client1
  /Client2

/UI Layer
  /CoreWebsite (views/models/etc)
  /WebsiteHelper (contains 'web' helpers appropriate for any website)
  /Tahiti.WebsiteHelpers (contains 'web' helpers only appropriate for Tahiti sites)

/BusinessLayer (logic projects for different 'frameworks')
  /Framework1.Business
  /Framework2.Business

/DataLayer
  /Framework1.Data
  /Framework2.Data

/Core (projects that are shared tools useable by any project/layer)
  /SharedLib1
  /SharedLib2

複数のプロジェクトで従来のn層設計をどのように拡張したかを説明した後、同様の状況でどのような決定を下したかについての経験を探しています（単純なUI、ビジネス、データ分離でさえあなたがすべてでした）使用）そしてあなたの決定のために何がより簡単/より困難でしたか。サブモジュールがどのように少し苦痛になる可能性があるかについての予備的な読書で私は正しいですか？利益の価値よりも多くの痛み？

私の直感的な反応は、タヒチの1つのリポジトリ（「クライアントプロジェクト」を除くすべてのプロジェクト）、次に各クライアントの1つのリポジトリに対するものです。私が推測しているタヒチのソース全体は、1万未満のファイルでなければなりません。これが私の推論です（そして私は批判を歓迎します）

  • Gitでは、「機能」と個々の「プロジェクト/ファイル」の履歴を追跡したいと考えています。プロジェクトを分離しても、「機能」は常に複数のプロジェクトにまたがっています。
  • コアサイトでコーディングされた「機能」は、ほとんどの場合、コアWebサイトと「フレームワーク」のすべてのプロジェクト（つまり、CoreWebsite、Framework1.Business、Framework1.Data）に最小限の影響を与えます。
  • 機能は複数のフレームワークに簡単にまたがることができます（実装する機能の10％はフレームワークにまたがると思います-CoreWebsite、Framework1.Business、Framework1.Data、Framework2.Business、Framework2.Data）
  • 同様に、機能では1つ以上のSharedLibプロジェクトや「UIウェブサイトヘルパー」プロジェクトの変更が必要になる場合があります。
  • クライアントのカスタムコードへの変更は、ほとんどの場合、リポジトリに対してローカルであるだけであり、「機能変更セット全体」が何であるかを確認するために他のコンポーネントへの変更を追跡する必要はありません。
  • 機能がプロジェクトにまたがってスコープ全体を表示することを考えると、各プロジェクトが独自のリポジトリである場合、リポジトリ全体の*すべての*コード変更を分析しようとするのは面倒だと思われますか？

前もって感謝します。

visual-studiogitvisual-sourcesaferepositoryrepository-design
29
Terry

ほとんどの人が別々のリポジトリを作成することを勧める理由は、それが変更と変更セットを分離するためです。誰かがクライアントプロジェクトに変更を加えた場合（実際には他の人に影響を与えないとあなたが言う）、誰かがコードベース全体を更新する理由はありません。関心のあるプロジェクトから変更を取得するだけです。

GitサブモジュールはSubversionのExternalsのようなものです。 gitリポジトリを設定して、それぞれが個別のレイヤーになるようにしてから、サブモジュールを使用して、さまざまな階層で必要なプロジェクトを含めることができます。

たとえば、次の場合：

/Core -- It's own git repository that contains it's base files (as you had outlined)
  /SharedLib1
  /SharedLib2

/UI Layer -- Own git repository 
  /CoreWebsite
  /WebsiteHelper
  /Tahiti.WebsiteHelpers
  /Core -- Git Submodule to the /Core repository
    /SharedLib1
    /SharedLib2

これにより、/ Coreリポジトリへの更新がUIレイヤーリポジトリに確実に取り込まれます。また、共有ライブラリを更新する必要がある場合は、5〜6のプロジェクトで更新する必要がないことも意味します。

14
Koby