私たちの仕事には、多くの基本機能を共有するいくつかの異なる.netアプリケーションがあります。クリーンなn層アーキテクチャを使用してこれらのアプリケーションを構築しましたが、同じ機能を何度か再実装したことに気付いたその瞬間にヒットしました。これは明らかにDRYに違反するため、修正する必要があります。すでに一般的なグルーコード（IoCの配線、ログ、設定）にNugetを使用していますが、すべてのアプリケーション間でデータ層とビジネス層を共有したいと考えています。このアイデアは、UIが実際に必要なビジネスレイヤーの部分のみを処理するというものです。
これは最初は簡単な問題のように見えますが、進行中の開発には落とし穴があり、どのように進めればよいかわかりません。すべてを支配するために1つのビジネスレイヤーを作成するとします。簡潔にするために、「Foundation」と呼びます。Foundationを使用するためにアプリケーションを移植しましたが、すべてが素晴らしいものです。Foundationはnugetを介してライトUIレイヤーに配布されており、見栄えが良いです。しかし、その後、アプリケーションに機能を追加し始め、トラブルに直面します。
プロジェクトAに取り組んでおり、Foundationの変更を必要とする新しい機能を追加するとします。Foundation（Foundation-A）に変更を加え、不安定なパッケージとしてNugetフィードにプッシュします。プロジェクトAは最新のnugetパッケージを取得し、すべてが良好です。一方、別の開発者がプロジェクトBに取り組んでいます。彼はソース管理から最新のFoundationを取得しますが、安定したブランチから取得するため、プロジェクトAの変更はありません。彼は変更を加え、Foundation-Bを作成しました。そして、すべてが良いです。しかし、その後、実際にコードを共有できるFoundation-AとFoundation-Bの実装機能を発見したため、それらを組み合わせます。一方、Foundation-Cは独自の変更を加えてそこに浮上しています。最終的に、Foundation-Bの運用準備が整いました。しかし、その後、プロダクションA、B、
これはうまくいくように思えますが、異なるデータベーススキーマで作業し、FoundationリポジトリのさまざまなブランチとプロジェクトA、B、Cリポジトリ間ですべてを同期させることを心配しています。おそらく多くの手作業が必要になるようで、エラーの可能性が広がります。これを可能な限り自動化したいと思います。
使用しているスタックは次のとおりです。C＃、継続的インテグレーションを備えたTFS、Nuget。当社のアプリケーションはすべて、さまざまな種類のASP.NETアプリケーションです。物事を簡単にする場合は、さまざまなSCMを検討します。
さまざまなソースコードブランチでNugetを正常に保つ方法を探しています。間違ったNugetパッケージを参照するため、誤って開発コードを本番環境にプッシュしたくありません。