次の方法で共有


ワークスペースの最適化

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

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 つのワークスペースで管理します。それぞれ、サーバー上のブランチ内のフォルダーを開発マシン上のフォルダーにマップします。

フォルダーのブランチへのマッピングを示す図。

次のステップ

効率的なブランチ戦略を選択する