Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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 | Ograniczenie |
|---|---|
| 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 przypisane do elementu roboczego | 1000 |
| Tagi elementów roboczych przypisane do elementu roboczego | 100 |
| Zmiany 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 wersji elementu roboczego do 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 | Ograniczenie |
|---|---|
| Długie pole tekstowe | 1–M znaków |
| Tagi elementów roboczych przypisane do elementu roboczego | 100 |
| Łącza 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ń.
Zaległości, 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 | Ograniczenie |
|---|---|
| Zaległości | 10 000 elementów roboczych |
| Tablice | 1000 kart (z wyłączeniem tych kart w kategoriach proponowanego i ukończonegoprzepływu pracy) |
| Tablica zadań | 1000 zadań |
| Ścieżki obszaru | 10 000 na projekt |
| Głębokość ścieżki obszaru | 14 |
| Ścieżki obszaru dla zespołu | 300 |
| Ścieżki iteracji | 10 000 na projekt |
| Głębokość ścieżki iteracji | 14 |
| Ścieżki iteracji dla zespołu | 300 |
| Tablice projektowe | 500 na projekt. Dostępne na poziomie projektu i każda osoba mająca dostęp do projektu może używać. |
| Tablice zespołu | 500 na zespół. Specyficzne dla zespołu i używane do śledzenia metryk i danych specyficznych dla zespołu. |
| Zespoły | 5000 na projekt |
| Tagi elementów roboczych | 150 000 definicji tagów na organizację lub kolekcję |
| Plany dostarczania dla każdego projektu | 1000 |
| Szablony na typ elementu roboczego | 100 |
Każdy backlog może wyświetlać maksymalnie 10 000 elementów roboczych. Ten limit dotyczy tego, co lista prac może wyświetlać, 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:
- Przejrzyj użycie: 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 w backlogach i tablicach, gdy ich data zmiany jest starsza niż jeden 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 backlogu tego samego typu. Aby uzyskać więcej informacji, zobacz temat Rozwiązywanie problemów ze zmianą 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, harmonogramami prac i tablicami obowiązują następujące limity operacyjne. Domyślne i maksymalne limity.
| Interfejs użytkownika | Ograniczenie |
|---|---|
| Zaległości | 999 elementów roboczych |
| Tablice | 400 karty |
| Pulpity nawigacyjne dla każdego projektu | 500 |
| Tablica zadań | 800 elementów roboczych |
| Zespoły | 5000 na projekt |
| Tagi elementów roboczych | 150 000 definicji tagów na projekt |
| Szablony na typ elementu roboczego | 100 |
Każde zaległości mogą wyświetlać maksymalnie 999 elementów zadań. 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 backlogu 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 dostępu do 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 Odnośnik do elementu XML konfiguracji procesu.
Integracja z usługą GitHub
Jeśli zintegrowałeś swój projekt z usługą GitHub, obowiązują następujące limity.
| Integracja | Ograniczenie |
|---|---|
| Azure Boards: połączone repozytoria GitHub (UX) | 1000 repozytoriów na połączenie. |
| Azure Boards: połączone repozytoria GitHub (API) | 2000 repozytoriów na połączenie. Dowiedz się więcej. |
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 pewne doświadczenia, takie jak nawiązywanie połączenia z projektem w programie Visual Studio, mogą ulec pogorszeniu jakości. 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 Twojego doświadczenia w śledzeniu 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 w ramach 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 zaległości portfela zdefiniowane dla procesu | 5 | 5 |
| Kategorie zdefiniowane dla procesu | - | 32 |
| Listy globalne zdefiniowane dla procesu | - | 256 |
| Elementy zdefiniowane w globalnej liście | - | 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 XML można zdefiniować około 10 000 elementów we wszystkich listach globalnych określonych we wszystkich typach elementów roboczych.
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ść znaków 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 zaległości portfela zdefiniowane dla procesu | 5 | 5 |
| Kategorie zdefiniowane dla procesu | Nie dotyczy | 32 |
| Listy globalne zdefiniowane dla procesu | Nie dotyczy | 256 |
| Elementy zdefiniowane w globalnej liście | Nie dotyczy | 1024 |
Uwaga
W przypadku lokalnego modelu procesu XML można zdefiniować około 10 000 elementów dla wszystkich list globalnych określonych we wszystkich Rodzajach Elementów Roboczych.
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ółtworzą łączną dozwoloną liczbę pól 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 typów elementów roboczych.
- Ogranicz liczbę zdefiniowanych pól niestandardowych. Wszystkie pola niestandardowe współtworzą łączną dozwoloną liczbę pól 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 typów elementów roboczych.
- 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 mające zastosowanie tylko podczas przejścia lub reguły uzależnione od wartości innego pola, dodają dodatkowe warunki 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ń część WIT-ów albo wyeliminuj pewne reguły.
Limity szybkości
Aby zmniejszyć koszty oraz zwiększyć skalowalność i wydajność, Azure DevOps Services, podobnie jak wiele rozwiązań typu oprogramowanie jako usługa, korzysta z wielodzierżawności. 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).
Limity migracji i importu
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.