Śledzenie pracy, przetwarzanie i limity projektu

  • Artykuł

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 wybranych 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ń obowiązują następujące limity operacyjne.

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ń

Limit poprawki elementu roboczego wynosi 10 000 dla aktualizacji wprowadzonych za pośrednictwem interfejsu API REST dla usług Azure DevOps Services. Ten limit ogranicza aktualizacje z interfejsu API REST, jednak 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
Pulpity nawigacyjne zespołu 500 na zespół
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. Jest to limit wyświetlania listy prac, a nie limit liczby elementów roboczych, które można zdefiniować. Jeśli zaległość przekroczy ten limit, warto rozważyć dodanie zespołu i przeniesienie niektórych elementów roboczych do listy prac innego zespołu.

Dodatkowe uwagi:

  • Ukończone lub zamknięte elementy robocze nie są wyświetlane na listach prac i tablicach, gdy ich data zmiany jest większa niż rok. Nadal możesz wyświetlić te elementy przy użyciu zapytania. Jeśli chcesz, aby były wyświetlane na liście prac lub tablicy, możesz wprowadzić niewielką zmianę, która resetuje zegar do wyświetlania.
  • Unikaj zagnieżdżania elementów listy prac tego samego typu. Aby dowiedzieć się więcej, 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 dowiedzieć się więcej, zobacz Ograniczenia widoków tablic Kanban z wieloma zespołami.
  • Domyślnie limity elementów roboczych mogą być początkowo skonfigurowane pod kątem niższych 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, warto rozważyć dodanie zespołu i przeniesienie niektórych elementów roboczych do listy prac innego zespołu.

Dodatkowe uwagi:

W przypadku lokalnego modelu procesów XML można zmodyfikować limity listy prac i tablicy zadań, edytując plik ProcessConfiguration.xml. 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ą zacząć działać w sposób obniżony. W przypadku lokalnego serwera Azure DevOps Server nie ma ograniczeń liczby projektów. Mogą jednak wystąpić problemy z wydajnością, jeśli liczba projektów zbliża się do 300. Jeśli planujesz migrację kolekcji lokalnej do usług Azure DevOps Services, musisz zaobserwować maksymalny limit 1000 projektów. Jeśli kolekcja zawiera ponad 1000 projektów, musisz podzielić kolekcję lub usunąć starsze projekty.

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

Dostosowywanie procesu

Na liczbę obiektów, które można zdefiniować dla procesu, nakłada się szereg limitów. Aby dowiedzieć się więcej o modelach procesów, 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ż stanowią one twarde limity, mogą również mieć zastosowanie 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 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ć dodatkowe ograniczenia i wymagania zgodności modelu procesów hostowanego XML, zobacz Dostosowywanie procesu podczas korzystania z hostowanego kodu XML.

Uwaga

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

W poniższej tabeli wymieniono maksymalną liczbę obiektów, które można zdefiniować dla modeli procesów dziedziczenia i lokalnego kodu XML. Chociaż stanowią one twarde limity, mogą również mieć zastosowanie 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

Zalecamy rozważenie poniższych wskazówek w celu zminimalizowania problemów z wydajnością.

  • Zminimalizuj liczbę zdefiniowanych pól niestandardowych. Wszystkie pola niestandardowe współtworzyją łączną dozwoloną liczbę dozwolonych dla procesu, kolekcji lub organizacji. Należy pamiętać, że można określić różne zachowanie dla tego samego pola w innym WIT. Oznacza to, że można określić różne reguły, listy wyboru i nie tylko.
  • Zminimalizuj liczbę reguł zdefiniowanych dla funkcji WIT. Chociaż można utworzyć wiele reguł dla typu elementu roboczego, dodawanie reguł może negatywnie wpływać na wydajność, gdy użytkownik dodaje i modyfikuje elementy robocze. Gdy użytkownicy zapisują elementy robocze, system weryfikuje wszystkie reguły skojarzone z polami dla typu elementu roboczego. W pewnych warunkach wyrażenie weryfikacji reguły jest zbyt złożone, aby aparat SQL mógł je ocenić.
  • Zminimalizuj liczbę zdefiniowanych niestandardowych typów elementów roboczych.
  • Zminimalizuj liczbę zdefiniowanych pól niestandardowych. Wszystkie pola niestandardowe współtworzyją łączną dozwoloną liczbę dozwolonych dla procesu, kolekcji lub organizacji. Należy pamiętać, że można określić różne zachowanie dla tego samego pola w innym WIT. Oznacza to, że można określić różne reguły, listy wyboru i nie tylko.
  • Zminimalizuj liczbę reguł zdefiniowanych dla funkcji WIT. Chociaż można utworzyć wiele reguł dla typu elementu roboczego, dodawanie reguł może negatywnie wpływać na wydajność, gdy użytkownik dodaje i modyfikuje elementy robocze. Gdy użytkownicy zapisują elementy robocze, system weryfikuje wszystkie reguły skojarzone z polami dla typu elementu roboczego. W pewnych warunkach wyrażenie weryfikacji reguły jest zbyt złożone, aby aparat SQL mógł je ocenić.
  • Zminimalizuj liczbę zdefiniowanych niestandardowych typów elementów roboczych.
  • Zminimalizuj liczbę zdefiniowanych pól raportów. Pola z możliwością raportowania wpływają 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 zdefiniowanych dla projektu. Każdy kwalifikator behawioralny określony dla pola powoduje zwiększenie liczby wyrażeń podrzędnych. Zagnieżdżone reguły, reguły, które mają zastosowanie tylko w przypadku przejścia lub warunku wartości innego pola, powodują dodanie większej liczby 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. Usunięcie niektórych sieci WIT lub wyeliminowanie niektórych reguł może rozwiązać ten błąd.

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 zmniejszyć prawdopodobieństwo 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 nieoptymalizowania zapytań. Więcej informacji można znaleźć w następujących artykułach:

Migrowanie i importowanie limitów

Podczas określania migracji ze środowiska lokalnego do usług Azure DevOps Services istnieje kilka limitów rozmiaru, które mogą wystąpić. Te limity obejmują:

  • Rozmiar bazy danych jest większy niż zalecany rozmiar
  • Największy rozmiar tabeli jest większy niż zalecany rozmiar
  • Rozmiar metadanych bazy danych przekracza obsługiwany rozmiar

Aby dowiedzieć się więcej, 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.