6

私の日常業務ソリューションには、約 80 のプロジェクトがあります。このソリューションには、4 つの異なる Web サイト、ビジネス ロジック、およびインフラストラクチャ アセンブリ (拡張メソッド、さまざまなユーティリティ、リポジトリ基本クラスなど) が含まれています。

このソリューションは非常にうまく機能しますが、テスト プロジェクトをソリューションに追加すると、簡単に 100 を超えるプロジェクトを通過してしまい、このソリューションでの作業が非常に面倒になります。

解決策を探しているうちに、Nuget に非常に興味を持ち、それが役立つかどうか疑問に思うようになりました。

アイデアは、巨大なソリューションを小さなアトミック ピースに分割し、その出力がプライベート Nuget リポジトリにアップロードされる Nuget パッケージになるというものです。

Web サイトは、その特定の Web サイトにバインドされたクラス ライブラリ以外のパッケージを参照します。

CI の観点から:

各パッケージ ソリューションはアトミックである必要があります。

  • その参照をフェッチできる必要があります (公式フィードとプライベート フィードの両方からの他の NuGet パッケージ)。
  • 建てる
  • テストを実行する
  • パッケージを組み立てる
  • 新しいパッケージをリポジトリにアップロードします

製品ソリューション (Web サイトなど) は、次の後にビルドする必要があります。

  • コードのコミット
  • プライベート リポジトリの NuGet パッケージの更新

なにか提案を？それとも、この巨大なソリューションの分割を達成するためのより良い方法でしょうか?

4

2 に答える 2

6

パッケージ管理 (Windows の場合: NuGet) を使用することは、ここでは確実なアプローチです。依存関係の解決を「無料」で取得し、セマンティック バージョニングを利用して、パッケージのバージョン番号だけで意味のある情報をパッケージ コンシューマーに伝えることができます。

ただし、NuGet は事実上、いくつかのより基本的なパターンの特定の実装です。

  1. 変更されたビルド コードのみ
  2. システムを管理しやすい小さなユニットに分解する
  3. 「フレームワーク」を構築しない

あなたの質問から、あなたは必要以上に多くのコードを構築しているように思えます。NuGet を使用してコードをモジュール化すると、これら 3 つのパターンを実装するのに役立ちます (1 と 2 - 3 については追加の手順を実行する必要があります)。

これらのパターンを適用すると、@Fede も役立ちます (C および C++ コードを使用する場合、NuGet は適用されません)。一般に、ソフトウェアをよりモジュール化することで (ただし、通常 *.Library.dll または *.Common.dll などと呼ばれるモノリシックですべてを知っている「フレームワーク」を構築するという罠を回避します)、より優れたビルド アーキテクチャを実現できます。

最終的に、コードの各「チャンク」 (Visual Studio 用語ではプロジェクトまたはソリューション) は、1 人の開発者が理解できる必要があります。扱いにくい、または複雑すぎる場合は、分割してください。プロジェクト、ソリューション、.cs ファイルなどはすべて人間のための抽象化であり、機械のためのものではありません。そのため、サイズとそれらの間の関係は、人間の能力と理解の必要性を反映する必要があります。これをやりすぎると、1 つの機能を完成させるために複数のパッケージを変更する必要が生じます。この場合、定義による分離は細かすぎるため、一部のコードを再度グループ化する必要があります。

(情報開示: 私は Windows Package Management - PackageManagementBook.comの共著者です)

于 2013-10-30T02:05:59.630 に答える
0

おそらく、個々の Web サイトをそれぞれ別のソリューションに移動できます。バージョン管理ツールを使用している場合、これはおそらく論理的なステップです。個々のプロジェクトは個別にバージョン管理されるため、開発者は一度にすべてのプロジェクトと同期する必要がないからです。また、個々のウェブサイトは互いに独立している必要があるため、面倒な動きにはなりません。

特定の「ビジネス プロジェクト」に密接に関連していない一般的なコードや一般的なコードはありますか? このコードは、会社のフレームワークなどの別のソリューションに移動できます。その後、各ビジネス プロジェクトはリリースされたバージョンのフレームワークを使用し、ビジネス的に実行することが論理的であると思われる場合にのみアップグレードします。たとえば、Web サイト A のリリース スケジュールが現在タイトな場合、重大な変更を含むバージョンのフレームワークを導入することはお勧めできません。ただし、Web サイト B が重要ではないフェーズにある場合は、フレームワークの新機能を組み込み、少し余裕がある間に破壊的変更に対処することをお勧めします。

NuGet で要件を満たすことができるかどうかはわかりませんが、アトラシアンは、組織的な方法でこのようなことを達成するのに役立ついくつかのツール (FishEye、Crucible、Bamboo など) を提供しています。注: 私は Atlassian と提携していません。

于 2013-10-09T22:43:19.937 に答える