Ś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:
- 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 wielu zespołów. 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 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.