.Netのチーム開発環境
最近、開発をPHPからC＃/。Net Coreに切り替えた新しい会社に加わりました。彼らは、この新しい環境でゼロから新しいCMSを作成しています。
私の前には、この新しいシステムに取り組んでいる開発者は1人だけでした。彼は、かなり扱いにくいシステムをセットアップしました。私はそれを改善する方法を考えようとしていますが、関連するさまざまなツールの機能に関する情報を見つけるのに苦労しています。
警告：詳細な説明/許可の着信。 TL/DR：現在のシステムでは、日々の開発が非常に非効率になっています。必要に応じて、以下の具体的な質問にスキップできます。
現在のセットアップは次のように機能します。システムはコア部分と顧客固有の部分に分かれています。各部分は、責任の論理的な分割に従って、さらにいくつかの小さなプロジェクトに分割されます。ここまでは順調ですね。
これらの各プロジェクトは、独自の個別のGitリポジトリにあり、通常2つのプロジェクト、機能を含む1つのクラスライブラリ、および1つの単体テストプロジェクトを含む単一のソリューションで構成されます。 （時々、そのようなペアが複数存在しますが、私は事故だと思います。）
GitリポジトリはTFSでホストされています。 TFSは、コミットがプッシュされると各ソリューションを自動的にビルドし、ビルドの結果をNuGetパッケージとして公開します。さまざまなプロジェクト間の依存関係は、NuGetの依存関係によって排他的に処理されます。
これには多くの問題があります。
新しい機能が必要な場合、必要な変更は多くの場合、複数のプロジェクトに分割されます。 CMSは非常に新しいため、多くの新機能ではコアへの追加が必要です。さらに、新しい機能では、顧客固有のパーツの複数のプロジェクトの変更が必要になる場合があります。ビューコントローラーレイヤー（1つのプロジェクト）、システムレイヤー（別のプロジェクト）、および一部のデータレイヤー（まだ別のプロジェクト）です。
依存関係の動作方法のため、これを実現するには、依存関係グラフの最後でプロジェクトを変更し、コミットしてプッシュし、サーバーが新しいパッケージを公開するのを待ち、次のレイヤーを更新し、そこで変更を加え、コミットする必要があります最後のレイヤーに到達するまで、プッシュなどを行います。このプロセスのどの時点でも、互換性のない方法で何かを変更すると、ワールドビルドが壊れることがあります。
ご想像のとおり、これは非常に非効率的なプロセスです。また、下層の変更が正しくないか不十分であることに気付いた場合は、プロセスを最初からやり直す必要があります。これは、実際にはシステムの有用な状態ではないGitコミットを簡単に蓄積できることを意味します。さらに悪いことに、下位層で何かを試してみたい場合（たとえば、デバッグ出力を追加する場合）、実際にこれをコミットして公式リポジトリにプッシュしてビルドを取得し、後で別のコミットを追加して効果を元に戻す必要があります。
さらに、すべての小さなプロジェクトは独自のソリューションに含まれているため、それぞれをVisualStudioの独自のインスタンスで開く必要があります。現在、6つのインスタンスを実行しています。仕事に適したものを見つけることは時々混乱します。また、VS構成の動作方法により、行ったインスタンスが最後にシャットダウンされていない場合、行った変更（ツールウィンドウのレイアウトなど）が上書きされるリスクがあります。
最後に、ビルド中のNuGetパッケージはリリースバージョンであるため、スタックを介したデバッグは最適ではありません。 （また、現在、パッケージにシンボル情報やソースがないため、デバッグは完全に不可能ですが、この特定の問題を修正する方法は知っています。）
質問
CIビルドのNuGet依存関係設定と開発者ビルドの単一ソリューションプロジェクト依存関係設定の両方を行う方法はありますか？
ここでのNuGetの使用法はさらに役に立ちますか？多数のGitリポジトリにまたがるプロジェクトを作成するためのより良い方法はありますか？
ビルドが自動的に適切なバージョン番号でプッシュされる、予測可能な方法でサーバーをオーバーライドする開発者ローカルのNuGetリポジトリを作成する方法はありますか？ 2人の開発者が同じリポジトリで同時に作業する場合の同期の問題についてはかなり心配しています。
コア用に1つのGitリポジトリにマージし、顧客固有のものごとに1つにマージすることは、大きなメリットになりますか？
言い換えれば、一般的に良い開発設定は何ですか？残念ながら、私が.Net開発に取り組むのはこれが初めてなので、一般的に経験が不足しています。
これは非常にうまく設定されているように私には聞こえます。
日々の開発生活を楽にするためにできることがいくつかあります。
問題1：依存プロジェクトで使用する前にnugetsを公開する必要がある
バージョン番号に-betaを追加することで、ローカルビルドからプレリリースnugetを手動で公開できます。依存プロジェクトは、「実際の」バージョンをコミットする前に、このプレリリースバージョンを使用するように更新してテストできます。
または、テストnugetをマシンにパッケージ化し、ディレクトリにコピーします。このディレクトリをVSのローカルnugetリポジトリとして設定します
または、プロジェクトの参照をローカルにあるdllに変更できます
問題2：リリースコンパイルされたnugetsのデバッグ。
理想的にはここでこれを行う必要はありません。 nugetプロジェクトに単体テストを記述して、正しく機能することを確認します
ただし、デバッグバージョンをコンパイルしてプレリリースとして使用するか、ローカルのNugetリポジトリにポップすることができます
- あなたが探しているものを正しく理解している場合は、 SlimJim というツールがあります。これは、すべての構成パッケージをプロジェクト参照に置き換えてソリューションを変更することで、これに対処するのに役立ちます。
- つまり、コアのバージョンごとに異なる顧客固有のパーツを使用できます。あなたがそれを望まないのなら、それはおそらくあなたを助けていないでしょう。サブモジュールやサブツリーを試すこともできますが、この場合は役に立ちません。
- ローカルワークスペースから中央フィードに公開しないでください。ローカルディレクトリからパッケージソースをホストできます。詳細は、使用しているVisual Studioのバージョンによって異なりますが、 この記事 から始める必要があります。
- かなり新しいアプリケーションと現在小さいアプリケーションに、はるかに大きなアプリケーションのプロジェクト構造を使用しているように見え、過剰なオーバーヘッドが発生しているようです。