ワークスペースの最適化

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020

Visual Studio 2019 |Visual Studio 2022

チームに大規模で複雑なコードベースがある場合は、ワークスペースを最適化して、必要なファイルのみを含めることができます。 ワークスペースを最適化すると、パフォーマンスが向上し、ネットワーク トラフィックが削減され、開発マシンに必要なディスク領域が削減されます。

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

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

有効なフォルダー名に関するその他のヒント:

• すべてのフォルダー、サブフォルダー、およびファイル名を短くして作業を簡略化し、一部の種類のコード プロジェクトで発生する可能性のある長いパスの問題を回避します。

• コマンド ライン操作の実行を容易にするために、ファイル名とフォルダー名に空白を使用しないようにします。

ワークスペースの最適化

チームのコードベースが大きい場合は、ワークスペース フォルダーのマッピングを最適化することで、時間、ネットワーク帯域幅、およびローカル ディスク領域の無駄を回避できます。 明示的、暗黙的、クローク、および非再帰的なフォルダー マッピングを使用して、より簡単かつ迅速に使用可能なワークスペースを作成できます。

フォルダーをワークスペースにマップする場合は、ローカル ビルドを作成するために必要なすべてのファイルを取得するのに十分な高さがあるが、必要以上に多くのファイルを取得できないほど低いフォルダーをコード ツリーで選択していることを確認します。 次のワークスペースの例では、 $/SiteApp/ を c:\code\SiteApp\ にマップするだけです。 このような単純なワークスペースでは、$/SiteApp/Main/ 内のすべてのフォルダーが、必要なファイルを含むワークスペースに暗黙的にマップされます。

このアプローチの主な問題は、不要な多くのファイルを提供し、時間とリソースを無駄にすることです。 たとえば、カスタマイズされたビルド プロセスを開発しない場合、 $/SiteApp/BuildProcessTemplates/ は必要ありません。

時間の経過とともに、チームのコードベースが拡大することが予想され、 $/SiteApp/Main/に追加されたすべての新しいコードを自動的にダウンロードする必要はありません。 他のフォルダーで作業しているチームがこれらのファイルを変更すると、サーバーから最新のファイルを取得すると、不要なファイルの更新を待つ時間が長くなる可能性があります。

ワークスペースを最適化して、よりカスタマイズされたフォルダー マッピングを作成できます。

1. Visual Studio ソース管理エクスプローラーで、[ ワークスペース] の横にあるドロップダウン矢印を選択し、[ ワークスペース] を選択します。

2. [ ワークスペースの管理 ] ダイアログ ボックスで、最適化するワークスペースを選択し、[ 編集] を選択します。

3. [ ワークスペースの編集 ] ダイアログ ボックスで、ワークスペースマッピングを編集します。

   

4. たとえば、コードを開発するには、 DinnerNow プロジェクトのコード プロジェクトが必要です。 $/Fabrikam TFVC/DinnerNow/feature3 など、ソリューションに各コード プロジェクトを明示的に含めるのではなく、$/Fabrikam TFVC/DinnerNow をマップし、必要なコード プロジェクトを含むすべてのサブフォルダーを暗黙的にマップできます。

5. $/Fabrikam TFVC/DinnerNow/feature1 または $/Fabrikam TFVC/DinnerNow/feature2 のファイルは必要ありませんが、暗黙的にマップされるため、2 つのクロークされたマッピングを使用してワークスペースからこれらのフォルダーを除外できます。

6. チームは、いくつかの基本的なライブラリのセットを維持し、場合によっては拡張します。 このフォルダーには現在のほぼすべてのライブラリが必要であり、チームが今後そこに追加するライブラリが必要になると予想されるため、 $/Fabrikam TFVC/Main/ をマップします。

7. $ /Fabrikam TFVC/Main/ClassLibrary という大きなフォルダーの小さなセグメントのみが必要なので、それをクロークとしてマップし、必要なサブフォルダー である $/Fabrikam TFVC/Main/ClassLibrary1 のみを明示的にマップします。

8. ClassLibrary1 内の一部のファイルはすぐに必要ですが、サブフォルダーの内容は必要ないため、$/Fabrikam TFVC/Main/ClassLibrary1/ フォルダーに非再帰的マッピングを適用します。

ソース管理エクスプローラーでマップされていないブランチまたはフォルダーを右クリックし、[詳細]、[>を選択して、フォルダーをワークスペースにマップすることもできます。 または、ソース管理エクスプローラーの上部にある [ローカル] フォルダーの横にある [マップされていない] リンクを選択します。 サブフォルダー間でマッピングを再帰的にする場合は、[ マップ ] ダイアログ ボックスでマップ先のローカル フォルダーを選択し、[ 再帰 ] チェック ボックスをオンにします。

次のスクリーンショットは、 ソース管理エクスプローラー のサーバー ツリーとコンピューター上のローカル ファイルにこれらのワークスペースの最適化を適用した結果を示しています。

ワークスペースを使用してブランチを分離する

組織でブランチを使用してコードベースのリスクを分離する場合は、作業するブランチごとに個別のワークスペースを作成できます。 小規模なチーム内で作業を続けますが、いくつかのワークスペースを使用して、複数のブランチで行う作業を管理します。

例えば次が挙げられます。

• 機能の開発: Extranet ブランチで作業するように既定のワークスペースを変更し、顧客向け Web サイトの開発に参加します。

• 統合と安定化: Test ブランチと Dev ブランチで作業を行う 2 つの新しいワークスペースを作成します。このブランチでは、他の開発者やテスト担当者と共同作業を行い、統合中にコードを安定させます。

3 つのワークスペースで作業を管理します。各ワークスペースは、サーバー上のブランチ内のフォルダーを開発マシン上のフォルダーにマップします。

次のステップ

効果的な分岐戦略を選択する