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.
W Eksploratorze kontroli źródła programu Visual Studio wybierz strzałkę listy rozwijanej obok pozycji Obszary robocze i wybierz pozycję Obszary robocze.
W oknie dialogowym Zarządzanie obszarami roboczymi wybierz obszar roboczy, który chcesz zoptymalizować, a następnie wybierz pozycję Edytuj.
W oknie dialogowym Edytowanie obszaru roboczego edytuj mapowania obszarów roboczych.
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.
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.
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/.
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.
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.
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:
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 iDev
, 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.