ワークスペースの最適化

 

発行: 2016年4月

大規模で複雑なコードベースをチームで使用している場合は、 必要なファイルだけをワークスペースに含めるようにすると、パフォーマンスの向上とネットワーク トラフィックの軽減に役立ち、開発用コンピューターに必要なディスク領域の削減にもつながります。

• フォルダーの名前を最適化する

• 明示的、暗黙的、クローク、および非再帰的なフォルダー マッピングを使用してワークスペースを最適化する

• ワークスペースを使って異なる分岐の作業を分離し管理する

フォルダーの名前を最適化する

サーバーでまだ分岐を使用していない場合は、Main というサブフォルダーにコードをすべて配置します (例: $/TFVCTeamProject/Main/)。 こうすると、分岐が必要になるほどチームが大きくなっても、コードベースを管理できます。 開発用コンピューターで、C:\Users\YourName\Source\Workspaces\TFVCTeamProject\Main\SolutionName\ のように、プロジェクトの構造に一致する短く理解しやすいフォルダー パスを使用する必要があります。

効果的なフォルダー名のヒントをさらに以下に挙げます。

• フォルダー名、サブフォルダー名、ファイル名を短くすると、作業が単純になり、ある種のコード プロジェクトでパスが長いことによって発生する可能性のある問題を回避できます。

• 名前に空白を含めないようにすると、コマンド ライン操作が少しだけ楽になります。

明示的、暗黙的、クローク、および非再帰的なフォルダー マッピングを使用してワークスペースを最適化する

コードベースが大きい場合、ワークスペースのフォルダー マッピングを最適化すると、時間やネットワーク帯域幅、ローカル ディスク容量を無駄にしないで済みます。

フォルダー マッピングを使うときは、ローカル ビルドの作成に必要なファイルをすべて取得できるように、コード ツリーの上位フォルダーを選択します。ただし、必要以上に多数のファイルが取得されない深さのフォルダーを選択します。 また、明示的、暗黙的、クローク、非再帰的 というフォルダー マッピングを使用して、使いやすいワークスペースをもっと簡単にすばやく作成することもできます。

架空の開発者であるライザのワークスペースが以下に示されています。これを見ると、なぜ単純に $/SiteApp/ を c:\code\SiteApp\ にマップして、それで済まさないのか不思議に思えるかもしれません。 このような単純なワークスペースは、暗黙的に 必要なすべてのフォルダーを $/SiteApp/Main/ にマップしています。

この方法による大きな問題は、ユーザーが必要としない多数のファイルも見えるため、時間とリソースの無駄になることです。 このためライザは、調整したフォルダー マッピングを作成します。

	ライザはビルド処理をカスタマイズしないため、$/SiteApp/BuildProcessTemplates は不要です。 やがてコードベースが増加することが予想されるため、$/SiteApp/Main/ に追加された新しいコードをすべて自動的にダウンロードすることも望ましくありません。 他のフォルダーで作業するチームがファイルを変更しているときに、ライザがサーバーから最新のファイルを取得した場合、自分が必要としないファイルへの更新を長時間待たされる可能性があります。 ライザが自分のコードを作成するには、FabrikamFiber ソリューションを構成するすべてのコード プロジェクトが必要です。 各コード プロジェクトを明示的に含めるのではなく (たとえば、$/SiteApp/Main/FabrikamFiber/FabrikamFiber.DAL)、代わりに $/SiteApp/Main/FabrikamFiber/ をマップして、暗黙的に彼女が必要とするコード プロジェクトを含むすべてのサブフォルダーをマップします。
	ライザには $/SiteApp/Main/FabrikamFiber/3DModels または $/SiteApp/Main/FabrikamFiber/Docs にあるファイルが不要ですが、これらは によって暗黙的に割り当てられるため、2 つのクローク マッピングを使用して、自分のワークスペースからこれらのフォルダーを除外します。
	ライザとチームの他のメンバーは、基本的なライブラリを維持していますが、これに追加を行うこともあります。 彼女はこのフォルダーにあるほとんどすべての最新ライブラリを必要とし、自分のチームが将来そのフォルダーに追加するライブラリも必要になると予想しているため、$/SiteApp/Main/libraries/Common をマップします。
	ライザは、大きなフォルダー $/SiteApp/Main/libraries/Common/LibraryC のごく一部のみが必要であるため、このフォルダーをクロークとしてマップし、自分が必要とするとサブフォルダー $/SiteApp/Main/libraries/Common/LibraryC/Sub-Library1 を明示的にマップします。
	ライザは LibraryD 内の一部のファイルをすぐに必要としていますが、そのサブフォルダー内の大部分は必要としないため、このフォルダーに $/SiteApp/Main/libraries/Specialized/LibraryD/* という非再帰的マッピングを適用します。

ワークスペースを使って異なる分岐の作業を分離し管理する

会社のコードベースで分岐を使ってリスクを分離している場合、作業対象の分岐ごとに独立したワークスペースを作成する必要があります。

たとえば、Fabrikam Fiber 社で、コードベースとスタッフが増加したとします。 多くのチームの間でリスクを分離するために、コードベースが分岐されます。 ライザは自分の小規模なチーム内で作業を継続しますが、複数の分岐で行う作業を管理するために、いくつかのワークスペースを使用します。

	機能の開発: 彼女は既定のワークスペースを Extranet 分岐を作業対象とするように変更して、この分岐で顧客に対面する Web サイトの開発に参加します。
	統合と安定化: 彼女は 2 つの新しいワークスペースを作成して、Test 分岐と Dev 分岐で作業を行い、他の開発者やテスト担当者と連携して統合時にコードが安定して使うことができるようにします。

ライザは、それぞれがサーバー上の分岐のフォルダーを自分の開発コンピューター上のフォルダーにマップした、3 つのワークスペースで自分の作業を管理します。

注意

分岐や中断 (または棚上げ) は同じコードベースに対する異なる作業を分離する場合に好まれる方法です。ただし、どちらの方法も要件を満たさない場合は、同じサーバー フォルダーを複数のワークスペースにマップできます。ほとんどの場合、この方法を使う必要はありません。実際に同じサーバー フォルダーを複数のワークスペースにマップする場合は、各ワークスペースに格納されている同じファイルに対して独立した異なる保留状態の変更が生じる可能性があることを忘れないでください。