小規模チーム向けのコード共有のワークフロー
問題は、実装ごとに異なる小さなCMSを開発したことです（現在）。
もちろん、これの開発は決して完全ではありません。時々、それを実装する複数のプロジェクトに取り組んでおり（CMSのコードファイルを各プロジェクトにコピーして貼り付けることによって）、他のプロジェクトでも共有したい新しい機能を追加します（これらは小さい場合があります）それらも、つまりカスタムajax JSONコントローラー-MVCを使用します）
私たちがやりたいのは、バージョン管理システム（または同様のもの）を介して他のすべてのプロジェクトとコードを迅速かつ均一に共有し、これは私たちが持っているあまり良いワークフローではないことがわかっているので、一般的にワークフローを整理することです。あなたは何を提案しますか？
また、現時点で使用しているソフトウェアはVisual Studio 2010であるため、TFSを強く検討していますが、それを取得しても、理想的なワークフローがわからない場合や、TFSが目的をサポートしている場合でも同様です。
編集：また、プロジェクト領域でのみ保持したいCMSベースを変更した特定の実装があることにも注意してください。 （つまり、ベースCMSコードと共有したくない特定の機能）
これは、選択したバージョン管理の問題ではなく、製品アーキテクチャの問題です。非常に 同様の質問 この問題に挑戦しているのはあなただけではないことがわかります。
一般的なアドバイスは、実装間のコピー＆ペーストを避けることです。これは明らかに、製品のコアに単一のブランチがあり、顧客固有の機能が別々のブランチに（ただしコアなしで）実装されている場合、または製品の構成を介してのみ実行できます。 3人以上の顧客が同じ機能を必要としている場合は、その機能をメインブランチに移動し、再利用および構成可能にします（したがって、不要な顧客に対してはオフにすることができます）。
お気づきのように、私は「2つ以上」について言及しました。これは、機能を再利用可能でグローバルに利用可能なものに変換するために必要なコストを重み付けするための再利用性についての私自身の仮定です。同じ機能を必要としている2人の顧客は、まだこの取り組みを実行できないと思います。また、通常、2人の顧客では再利用性を定義するのに十分ではありませんが、3人以上の顧客から要件を収集すると、通常、再利用可能で構成可能な機能を定義するための一連の適切な要件が得られます。
マルチカスタマーアプリケーションには他にも問題があります。たとえば、アプリケーションやサービスの代わりにアプリケーションとカスタマイズを販売する場合、新しい機能を顧客に直接実装すると（顧客が支払う時間内に）、機能自体が顧客とあなたの所有物であるという状況につながる可能性があるため、これに問題が生じる可能性があります機能の所有者が許可するまで、他の顧客には使用できません（必要な場合でも）-ライセンスを販売します（ただし、顧客との正しい合意がない場合、この問題は現在の状況でもすでに存在する可能性があります）。
まず、実際にソース管理を使用する必要があります。これは、共有する手段ではなく、変更が記録されるようにする手段です。
コードの共有に関しては、これらのアプリケーションの共通部分、つまり変更されないものを特定する必要があります。これらを取得して、それらからプロジェクト（またはプロジェクトのセット）を作成します。理想的には、純粋なコードであり、マークアップのないものです。これにより、カスタマイズされたすべてのプロジェクトで使用される共有DLLが生成されます。
マークアップに関しては-あなたcould似たようなことをしますが、UIはプロジェクト間で異なる傾向があるので、それがどれだけ使用されるかはわかりません。