Udostępnij za pośrednictwem


Śledzenie pracy, przetwarzanie i limity projektu

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

W tym artykule zdefiniowano limity operacji i obiektów nakładane na operacje śledzenia pracy i dostosowywanie śledzenia pracy. Oprócz określonych limitów twardych dla określonych obiektów obowiązują pewne praktyczne limity. Podczas dostosowywania typów elementów roboczych (WIT) należy wziąć pod uwagę limity nakładane na obiekty.

Elementy robocze i zapytania

Podczas definiowania elementów roboczych lub uruchamiania zapytań należy pamiętać o następujących limitach operacyjnych:

Objekt Limit
Załączniki dodane do elementu roboczego 100
Rozmiar załącznika 60 MB
Długie pole tekstowe 1–M znaków
Czas wykonywania zapytania 30 sekund
Wyniki zapytania 20 000 elementów
Długość zapytania 32 000 znaków
Udostępnione zapytania w folderze 999 zapytań
Łącza elementu roboczego przypisane do elementu roboczego 1000
Tagi elementów roboczych przypisane do elementu roboczego 100
Poprawki elementów roboczych (interfejs API REST) 10,000
Ulubione zapytania na projekt 200 zapytań

Interfejs API REST dla usługi Azure DevOps Services wymusza limit poprawki elementu roboczego 10 000 aktualizacji. Ten limit ogranicza aktualizacje wprowadzone za pośrednictwem interfejsu API REST, ale nie ma to wpływu na aktualizacje z portalu internetowego.

Objekt Limit
Długie pole tekstowe 1–M znaków
Tagi elementów roboczych przypisane do elementu roboczego 100
Łącza elementu roboczego przypisane do elementu roboczego 1000
Załączniki dodane do elementu roboczego 100
Rozmiar załącznika Od 4 MB do 2 GB
Czas wykonywania zapytania 6 minut
Wyniki zapytania 20 000 elementów
Długość zapytania 32 000 znaków
Udostępnione zapytania w folderze 999 zapytań
Ulubione zapytania na projekt 200 zapytań

Domyślny maksymalny rozmiar załącznika to 4 MB. Maksymalny rozmiar można zmienić do 2 GB.

Aby poprawić wydajność zapytań, zobacz Definiowanie zapytania/najlepszych rozwiązań.

Listy prac, tablice, pulpity nawigacyjne i zespoły

Podczas pracy z zespołami, tagami elementów roboczych, listami prac i tablicami obowiązują następujące limity wyświetlania operacyjnego i obiektów.

Interfejs użytkownika Limit
Listy prac 10 000 elementów roboczych
Boards 1000 kart (z wyłączeniem tych kart w kategoriach stanu proponowanego i ukończonego przepływu pracy)
Tablica zadań 1000 zadań
Ścieżki obszaru 10 000 na projekt
Głębokość ścieżki obszaru 14
Ścieżki obszaru na zespół 300
Ścieżki iteracji 10 000 na projekt
Głębokość ścieżki iteracji 14
Ścieżki iteracji na zespół 300
Pulpity nawigacyjne projektu 500 na projekt. Dostępne na poziomie projektu i każda osoba mająca dostęp do projektu może używać.
Pulpity nawigacyjne zespołu 500 na zespół. Specyficzne dla zespołu i używane do śledzenia metryk i danych specyficznych dla zespołu.
Teams 5000 na projekt
Tagi elementów roboczych 150 000 definicji tagów na organizację lub kolekcję
Plany dostarczania na projekt 1000
Szablony na typ elementu roboczego 100

Każda zaległości może wyświetlać maksymalnie 10 000 elementów roboczych. Ten limit dotyczy wyświetlania listy prac, a nie liczby elementów roboczych, które można zdefiniować, ponieważ nie ma określonego limitu. Jeśli zaległość przekroczy ten limit, rozważ dodanie zespołu i przeniesienie niektórych elementów roboczych do listy prac nowego zespołu.

Napiwek

Jeśli zbliżasz się do limitów pulpitów nawigacyjnych, zapoznaj się z następującymi krokami, aby zarządzać pulpitami nawigacyjnymi i czyścić je:

  • Przeglądanie użycia: zidentyfikuj pulpity nawigacyjne, które nie są już używane lub są duplikatami. Możesz to zrobić, sprawdzając datę ostatniego dostępu lub konsultując się z członkami zespołu.
  • Konsoliduj pulpity nawigacyjne: połącz podobne pulpity nawigacyjne, aby zmniejszyć łączną liczbę. Można to zrobić, dodając wiele widżetów do jednego pulpitu nawigacyjnego.
  • Archiwizowanie starych pulpitów nawigacyjnych: jeśli niektóre pulpity nawigacyjne nie są już potrzebne, ale chcesz zachować dane, rozważ wyeksportowanie danych i archiwizowanie pulpitów nawigacyjnych.
  • Użyj funkcji Śledzenie limitów obiektów: zapewnia wgląd w użycie zasobów w czasie rzeczywistym, w tym pulpity nawigacyjne. Ta funkcja może pomóc w proaktywnym zarządzaniu limitami i unikaniu potencjalnych problemów.

Inne uwagi:

  • Ukończone lub zamknięte elementy robocze nie są wyświetlane na listach prac i tablicach, gdy ich data zmiany jest starsza niż rok. Nadal możesz wyświetlić te elementy przy użyciu zapytania. Aby je wyświetlić na liście prac lub tablicy, wprowadź niewielką zmianę w celu zresetowania zegara wyświetlania.
  • Unikaj zagnieżdżania elementów listy prac tego samego typu. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z zmienianiem kolejności i zagnieżdżaniem.
  • Unikaj przypisywania tych samych ścieżek obszaru do więcej niż jednego zespołu. Aby uzyskać więcej informacji, zobacz Ograniczenia widoków tablic z wieloma zespołami.
  • Domyślnie limity elementów roboczych mogą być początkowo ustawione na niższe wartości.

Podczas pracy z zespołami, tagami elementów roboczych, listami prac i tablicami obowiązują następujące limity operacyjne. Domyślne i maksymalne limity.

Interfejs użytkownika Limit
Listy prac 999 elementów roboczych
Boards 400 kart
Pulpity nawigacyjne na projekt 500
Tablica zadań 800 elementów roboczych
Teams 5000 na projekt
Tagi elementów roboczych 150 000 definicji tagów na projekt
Szablony na typ elementu roboczego 100

Każda zaległości może wyświetlać maksymalnie 999 elementów roboczych. Jeśli zaległość przekroczy ten limit, rozważ utworzenie zespołu i przeniesienie niektórych elementów roboczych do listy prac nowego zespołu.

Inne uwagi:

W przypadku lokalnego modelu procesów XML można zmodyfikować limity listy prac i tablicy zadań, edytując ProcessConfiguration.xml plik. Aby uzyskać szczegółowe informacje, zobacz Informacje o elemencie XML konfiguracji procesu.

Projekty

Usługa Azure DevOps Services ogranicza każdą organizację do 1000 projektów na organizację, co zwiększa się o poprzedni limit 300 projektów.

Uwaga

Powyżej 300 projektów niektóre środowiska, takie jak nawiązywanie połączenia z projektem z programu Visual Studio, mogą ulec pogorszeniu. W przypadku lokalnego serwera Azure DevOps Server nie ma twardych ograniczeń, ale mogą wystąpić problemy z wydajnością, ponieważ liczba projektów zbliża się do 300. Podczas migracji do usług Azure DevOps Services należy przestrzegać maksymalnego limitu 1000 projektów. Jeśli kolekcja przekroczy ten limit, podziel kolekcję lub usuń starsze projekty.

Aby uzyskać więcej informacji, zobacz Migrowanie danych z usługi Azure DevOps Server do usług Azure DevOps Services.

Dostosowywanie procesu

Wiele limitów jest nakładanych na liczbę obiektów, które można zdefiniować dla procesu. Aby uzyskać więcej informacji, zobacz Dostosowywanie środowiska śledzenia pracy.

W poniższej tabeli wymieniono maksymalną liczbę obiektów, które można zdefiniować dla modeli procesów dziedziczenia i hostowanego kodu XML. Chociaż te limity są twardymi limitami, mogą być również stosowane praktyczne limity.

Objekt Dziedziczenie Hostowany kod XML
Liczba procesów, które można mieć w organizacji 128 64
Typy elementów roboczych zdefiniowane dla procesu 64 64
Pola zdefiniowane dla organizacji 8192 8192
Pola zdefiniowane dla procesu 1024 1024
Pola zdefiniowane dla typu elementu roboczego 1024 1024
Listy wyboru zdefiniowane dla organizacji lub kolekcji 2048 -
Elementy listy wyboru zdefiniowane dla listy 2048 2048
Długość znaku elementu listy wyboru 256 -
Stany przepływów pracy zdefiniowane dla typu elementu roboczego 32 16
Reguły zdefiniowane dla typu elementu roboczego 1024 1024
Akcje zdefiniowane dla typu elementu roboczego 1024 1024
Akcje zdefiniowane dla reguły 10 10
Poziomy listy prac portfela zdefiniowane dla procesu 5 5
Kategorie zdefiniowane dla procesu - 32
Listy globalne zdefiniowane dla procesu - 256
Elementy listy zdefiniowane na liście globalnej - 1024
Rozmiar załącznika elementu roboczego 60 MB 60 MB

Aby uzyskać informacje na temat innych ograniczeń i wymagań zgodności modelu procesów Hostowany XML, zobacz Dostosowywanie procesu podczas korzystania z hostowanego kodu XML.

Uwaga

W przypadku modelu procesów hostowanego kodu XML można zdefiniować około 10 000 elementów we wszystkich listach globalnych określonych we wszystkich sieciach sieciowych.

W poniższej tabeli wymieniono maksymalną liczbę obiektów, które można zdefiniować dla modeli procesów dziedziczenia i lokalnego kodu XML. Chociaż te limity są twardymi limitami, mogą być również stosowane praktyczne limity.

Objekt Dziedziczenie Lokalny kod XML
Liczba procesów, które można mieć w organizacji 64 64
Typy elementów roboczych zdefiniowane dla procesu 64 64
Pola zdefiniowane dla kolekcji 8192 1024
Pola zdefiniowane dla procesu 1024 1024
Pola zdefiniowane dla typu elementu roboczego 1024 1024
Listy wyboru zdefiniowane dla kolekcji 1024 Nie dotyczy
Elementy listy wyboru zdefiniowane dla listy 2048 2048
Długość znaku elementu listy wyboru 256 Nie dotyczy
Stany przepływów pracy zdefiniowane dla typu elementu roboczego 32 16
Reguły zdefiniowane dla typu elementu roboczego 1024 1024
Poziomy listy prac portfela zdefiniowane dla procesu 5 5
Kategorie zdefiniowane dla procesu Nie dotyczy 32
Listy globalne zdefiniowane dla procesu Nie dotyczy 256
Elementy listy zdefiniowane na liście globalnej Nie dotyczy 1024

Uwaga

W przypadku lokalnego modelu procesów XML można zdefiniować przybliżoną sumę 10 000 elementów dla wszystkich list globalnych określonych we wszystkich sieciach sieciowych.

Limity praktyczne

Aby zminimalizować problemy z wydajnością, zalecamy wykonanie następujących wskazówek:

  • Ogranicz liczbę zdefiniowanych pól niestandardowych. Wszystkie pola niestandardowe współtworzyją łączną dozwoloną liczbę dozwolonych dla procesu, kolekcji lub organizacji. Można określić różne zachowania, takie jak reguły i listy wyboru, dla tego samego pola w różnych sieciach sieciowych.
  • Ogranicz liczbę reguł zdefiniowanych dla funkcji WIT. Chociaż można utworzyć wiele reguł dla funkcji WIT, inne reguły mogą negatywnie wpływać na wydajność podczas dodawania lub modyfikowania elementów roboczych przez użytkowników. Gdy użytkownicy zapisują elementy robocze, system weryfikuje wszystkie reguły skojarzone z polami dla tego typu elementu roboczego. W niektórych przypadkach wyrażenie weryfikacji reguły może być zbyt złożone, aby usługa SQL mogła efektywnie ocenić.
  • Ogranicz liczbę zdefiniowanych niestandardowych sieciowych.
  • Ogranicz liczbę zdefiniowanych pól niestandardowych. Wszystkie pola niestandardowe współtworzyją łączną dozwoloną liczbę dozwolonych dla procesu, kolekcji lub organizacji. Można określić różne zachowania, takie jak reguły i listy wyboru, dla tego samego pola w różnych sieciach sieciowych.
  • Ogranicz liczbę reguł zdefiniowanych dla funkcji WIT. Chociaż można utworzyć wiele reguł dla funkcji WIT, inne reguły mogą negatywnie wpływać na wydajność podczas dodawania lub modyfikowania elementów roboczych przez użytkowników. Gdy użytkownicy zapisują elementy robocze, system weryfikuje wszystkie reguły skojarzone z polami dla tego typu elementu roboczego. W niektórych przypadkach wyrażenie weryfikacji reguły może być zbyt złożone, aby usługa SQL mogła efektywnie ocenić.
  • Ogranicz liczbę zdefiniowanych niestandardowych sieciowych.
  • Ogranicz liczbę zdefiniowanych pól z możliwością raportowania. Pola z możliwością raportowania mogą mieć wpływ na wydajność magazynu danych.

Uwaga

Sprawdzanie poprawności reguł elementów roboczych przekracza limity SQL: pojedyncze wyrażenie SQL jest definiowane dla każdego projektu w celu sprawdzania poprawności elementów roboczych za każdym razem, gdy zostaną utworzone lub zaktualizowane. To wyrażenie rośnie wraz z liczbą reguł określonych dla wszystkich typów elementów roboczych w projekcie. Każdy kwalifikator behawioralny dla pola zwiększa liczbę wyrażeń podrzędnych. Zagnieżdżone reguły, reguły, które mają zastosowanie tylko w przypadku przejścia, lub reguły warunkowe dla wartości innego pola dodają więcej warunków do instrukcji IF. Gdy wyrażenie osiągnie określony rozmiar lub złożoność, program SQL nie może go już ocenić i wygenerować błąd. Aby rozwiązać ten błąd, usuń niektóre sieci WIT lub usuń niektóre reguły.

Limity szybkości

Aby zmniejszyć koszty i zwiększyć skalowalność i wydajność, usługi Azure DevOps Services, takie jak wiele rozwiązań typu oprogramowanie jako usługa, korzysta z wielu dzierżaw. Aby zapewnić dobrą wydajność i zminimalizować ryzyko awarii, usługa Azure DevOps Services ogranicza zasoby, z których mogą korzystać osoby, oraz liczbę żądań, które mogą wykonywać w określonych poleceniach. Po przekroczeniu tych limitów kolejne żądania mogą być opóźnione lub zablokowane.

Większość limitów szybkości jest osiągana za pośrednictwem wywołań interfejsu API REST lub niezoptymalizowanych zapytań. Aby uzyskać więcej informacji, zobacz Limity szybkości i Najlepsze rozwiązania (aby uniknąć osiągnięcia limitów szybkości).

Migrowanie i importowanie limitów

Podczas migracji ze środowiska lokalnego do usług Azure DevOps Services może wystąpić kilka limitów rozmiaru, w tym:

  • Rozmiar bazy danych przekraczający zalecany rozmiar
  • Największy rozmiar tabeli przekraczający zalecany rozmiar
  • Rozmiar metadanych bazy danych przekraczający obsługiwany rozmiar

Aby uzyskać więcej informacji, zobacz Migrowanie danych z usługi Azure DevOps Server do usług Azure DevOps Services i Rozwiązywanie problemów z błędami importowania i migracji.