... ソース管理。
あなたの質問を読んで、最初に頭に浮かんだのは、「ネットワーク共有でホストされているソース コードの同じコピーで作業しようとしている」ということでした。悪い、悪い、悪い。たとえそれが Web サイトであり、通常の実行状態で 1 か所からアクセスできるとしても、それは適切な開発方法ではありません。
Subversion または Mercurial のコピーを入手し、コードベースをチェックして、全員が定期的に変更をコミットしていることを確認してください。Subversion Server 自体は CollabNet から解放されています。GUI と IDE の統合を提供するために使用されるツールの一部はそうではありません (ただし、一部の優れたツールはそうです。一般的な Windows Explorer ベースのリポジトリ アクションについては TortoiseSVN を確認してください。一方、AnkhSVN は Visual Studio 用のフリーウェア プラグインであり、IDE 内からのコミット/更新を可能にします)。 .
このソース管理システムをセットアップすると、全員がコードベースの作業コピーをローカル マシンに「チェックアウト」し、必要なすべての変更を加えて、安定版ができたらそれらの変更を「チェックイン」できます作業バージョンは、他のすべての人が自分の作業コピーを更新することで取得できます。明らかに、これには、開発者のマシンが Web サイトの基本的なコピーを自分のマシンで実行するのに十分な能力を備えている必要があります (過去 4 年ほどのほとんどの PC では、IIS、SQL Server Express、および ASP のインスタンスを実行しても問題はありません)。開発者のみが参照する .NET サイト)。最新の作業コピーの外観と動作を確認するには、
SVN は、変更を「マージ」することによって同じファイルの複数のコミットを処理します。通常、2 つの開発者が同じコード行を異なる方法で変更した場合にのみ問題が発生します。誰かが他のユーザーを混乱させる可能性のあるコードベースに大規模で抜本的な変更を加えているが、それでも自分の作業コピーを「コミット」したい場合 (一般的にはバックアップ目的で良いことです)、その人はそのコードベースに基づいて「ブランチ」を切ることができます。現在のソースコードから更新してコミットし、完了したら、変更を「トランク」にマージします。
基本的に、プロジェクトに取り組んでいるすべての開発者は、同じソース コード セットで作業する必要があります。これは、開発者がバージョン管理から最初からダウンロードし、VS で開き、「ビルド」ボタンを押して実行できる単一のソリューションであることが理想的です。チームは、作業中のプロジェクトとソース ファイルについて互いに連絡を取り合い、定期的に (1 時間または 2 時間ごとに) 変更をコミットして、他の全員の変更を取得する必要があります。
独り占めして「継続的統合」サーバーを実装できます。チェックインごとに、このシステムは最新のソース コードをプルし、さまざまなテスト/メトリックの実行、ステージングへのプッシュなど、多数の自動化されたタスクを実行します。 「ビルド エージェント」は、別の一連のテストを実行したり、別のコミットに基づいて動作したりできます)。これは通常、テスト駆動型の開発手法に厳密に従っている場合に最大の価値があります。次に、CI サーバーは単体テストと統合テストを実行して、コードが開発者が考えているすべてのことを実行することを確認します。また、ルールが守られていること、コードがテストによって適切に実行されていることを確認するコード カバレッジも確認します。
異なるが重複するプロジェクトを公開するさまざまなソリューションで作業するという考えは、優れたものではありません。ホストされた仮想マシン環境内のリソース需要を削減するための戦略として、そのアプローチを一度だけ見たことがあります (特に ReSharper のようなコード分析ツールを使用して多くのプロジェクトをロードすると、古いシステムやエミュレーター/VPC セットアップに実際に負担がかかる可能性があります)。