Udostępnij za pośrednictwem


Optymalizowanie obszaru roboczego

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Visual Studio 2019 | Visual Studio 2022

Jeśli twój zespół ma dużą i złożoną bazę kodu, możesz zoptymalizować obszar roboczy tak, aby zawierał tylko potrzebne pliki. Optymalizacja obszaru roboczego zwiększa wydajność, zmniejsza ruch sieciowy i zmniejsza ilość miejsca na dysku wymaganego na maszynie dewelopera.

Uwaga

Rozgałęzianie i zawieszanie lub odłożenie to preferowane sposoby izolowania różnych prac nad tą samą bazą kodu. Jeśli jednak żadna z tych metod nie spełnia Twoich potrzeb, możesz zamapować ten sam folder serwera w więcej niż jednym obszarze roboczym. W większości przypadków nie należy tego robić.

Jeśli mapujesz ten sam folder serwera w więcej niż jednym obszarze roboczym, pamiętaj, że w każdym obszarze roboczym mogą być przechowywane oddzielne i różne oczekujące zmiany w tym samym pliku.

Optymalizowanie nazw folderów

Jeśli nie używasz jeszcze gałęzi, umieść cały kod w podfolderze o nazwie Main na serwerze, na przykład : $/TFVCTeamProject/Main/. Następnie będziesz gotowy, gdy zespół będzie wystarczająco duży, aby wymagać gałęzi do zarządzania bazą kodu. Na maszynie deweloperów należy użyć krótkiej, zrozumiałej ścieżki folderu zgodnej ze strukturą projektu, takiej jak C:\Users\<YourName>\Source\Workspaces\TFVCTeamProject\Main\SolutionName.

Kilka dodatkowych wskazówek dotyczących obowiązujących nazw folderów:

  • Zachowaj krótkie nazwy wszystkich folderów, podfolderów i plików, aby uprościć pracę i uniknąć potencjalnych problemów z długą ścieżką, które mogą wystąpić w niektórych typach projektów kodu.

  • Unikaj odstępów w nazwach plików i folderów, aby ułatwić wykonywanie operacji wiersza polecenia.

Optymalizowanie obszaru roboczego

Jeśli baza kodu twojego zespołu jest duża, możesz uniknąć marnowania czasu, przepustowości sieci i miejsca na dysku lokalnym, optymalizując mapowania folderów obszaru roboczego. Możesz użyć jawnych, niejawnych, zamaskowanych i niecyklicznych mapowań folderów w celu szybszego i szybkiego utworzenia użytecznego obszaru roboczego.

Podczas mapowania folderu do obszaru roboczego upewnij się, że wybrano folder wystarczająco wysoki w drzewie kodu, w którym uzyskasz wszystkie pliki potrzebne do utworzenia kompilacji lokalnej, ale na tyle mało, że nie masz więcej plików niż potrzebujesz. W poniższym przykładowym obszarze roboczym można po prostu mapować plik $/SiteApp/ na c:\code\SiteApp\. Prosty obszar roboczy, taki jak ten, niejawnie mapuje wszystkie foldery w folderze $/SiteApp/Main/ do obszaru roboczego, w tym do potrzebnych plików.

Głównym problemem z tym podejściem jest to, że zapewnia wiele plików, których nie potrzebujesz, a tym samym traci czas i zasoby. Jeśli na przykład nie tworzysz niestandardowych procesów kompilacji, nie potrzebujesz elementu $/SiteApp/BuildProcessTemplates/.

Wraz z upływem czasu oczekujesz, że baza kodu zespołu wzrośnie i nie chcesz automatycznie pobierać każdego nowego fragmentu kodu dodanego do pliku $/SiteApp/Main/. Ponieważ zespoły pracujące w innych folderach zmieniają te pliki, gdy otrzymujesz najnowsze pliki z serwera, mogą wystąpić długie opóźnienia w oczekiwaniu na aktualizacje plików, których nie potrzebujesz.

Możesz zoptymalizować obszar roboczy, aby utworzyć bardziej dostosowane mapowania folderów.

  1. W Eksploratorze kontroli źródła programu Visual Studio wybierz strzałkę listy rozwijanej obok pozycji Obszary robocze i wybierz pozycję Obszary robocze.

  2. W oknie dialogowym Zarządzanie obszarami roboczymi wybierz obszar roboczy, który chcesz zoptymalizować, a następnie wybierz pozycję Edytuj.

  3. W oknie dialogowym Edytowanie obszaru roboczego edytuj mapowania obszarów roboczych.

    Zrzut ekranu przedstawiający edytowanie obszaru roboczego w oknie dialogowym Edytowanie obszaru roboczego.

  4. Na przykład w celu opracowania kodu potrzebne są projekty kodu z projektu DinnerNow . Zamiast jawnie dołączać każdy projekt kodu w rozwiązaniu, taki jak $/Fabrikam TFVC/DinnerNow/feature3, można mapować $/Fabrikam TFVC/DinnerNow, a tym samym niejawnie mapować wszystkie podfoldery zawierające potrzebne projekty kodu.

  5. Nie potrzebujesz plików w katalogu $/Fabrikam TFVC/DinnerNow/feature1 lub $/Fabrikam TFVC/DinnerNow/feature2, ale ponieważ są one niejawnie mapowane, możesz użyć dwóch mapowań zamaskowanych , aby wykluczyć te foldery z obszaru roboczego.

  6. Twój zespół utrzymuje i czasami rozszerza zestaw niektórych podstawowych bibliotek. Potrzebujesz prawie wszystkich bieżących bibliotek w tym folderze i oczekujesz, że potrzebne biblioteki zespół doda tam w przyszłości, więc mapujesz $/Fabrikam TFVC/Main/.

  7. Potrzebujesz tylko małego segmentu dużego folderu $/Fabrikam TFVC/Main/ClassLibrary, więc mapujesz go jako zamaskowany, a następnie jawnie mapujesz tylko potrzebny podfolder $/Fabrikam TFVC/Main/ClassLibrary1.

  8. Niektóre pliki są potrzebne natychmiast w ramach klasy ClassLibrary1, ale nie potrzebujesz zawartości jego podfolderów, dlatego stosujesz mapowanie niecykliczne do folderu $/Fabrikam TFVC/Main/ClassLibrary1/ .

Foldery można również mapować do obszarów roboczych, klikając prawym przyciskiem myszy rozpakowany gałąź lub folder w Eksploratorze kontroli źródła i wybierając pozycję Mapa zaawansowana>do folderu lokalnego. Możesz też wybrać link Nie zamapowany obok folderu Lokalnego w górnej części Eksploratora kontroli źródła. W oknie dialogowym Mapa wybierz folder lokalny do mapowania, a następnie zaznacz pole wyboru Cyklicznego, jeśli chcesz, aby mapowanie było rekursywne między podfolderami.

Na poniższych zrzutach ekranu przedstawiono wyniki stosowania tych optymalizacji obszarów roboczych w drzewie serwera w Eksploratorze kontroli źródła i w plikach lokalnych na komputerze.

Zrzuty ekranu pokazujące efekty mapowań folderów.

Używanie obszarów roboczych do izolowania gałęzi

Jeśli twoja organizacja używa gałęzi do izolowania ryzyka w bazie kodu, możesz utworzyć oddzielny obszar roboczy dla każdej gałęzi, w której pracujesz. Możesz kontynuować pracę w małym zespole, ale używasz kilku obszarów roboczych do zarządzania pracą wykonaną w wielu gałęziach.

Na przykład:

Diagram przedstawiający wiele gałęzi.

  • Opracowywanie funkcji: zmodyfikuj domyślny obszar roboczy tak, aby działał w Extranet gałęzi, w której uczestniczysz w tworzeniu witryny internetowej dostępnej dla klientów.

  • Integracja i stabilizacja: utworzysz dwa nowe obszary robocze do pracy w Test gałęziach i Dev , w których współpracujesz z innymi deweloperami i testerami, aby ustabilizować kod podczas integracji.

Zarządzasz pracą w trzech obszarach roboczych, z których każda mapuje foldery w gałęzi na serwerze na foldery na maszynie dewelopera.

Diagram przedstawiający mapowanie gałęzi na foldery.

Następne kroki

Wybieranie efektywnej strategii rozgałęziania