Ś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 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 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 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:
- 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.
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ń. Aby uzyskać więcej informacji, zobacz następujące artykuły:
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 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.