Einschränkungen für Arbeitsnachverfolgung, Prozesse und Projekte

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019 | TFS 2018

In diesem Artikel werden Betriebs- und Objektbeschränkungen für Arbeitsnachverfolgungsvorgänge und Die Anpassung der Arbeitsnachverfolgung definiert. Neben den angegebenen harten Grenzwerten für ausgewählte Objekte gelten bestimmte praktische Grenzwerte. Berücksichtigen Sie beim Anpassen von Arbeitselementtypen (WITs) die Grenzwerte für Objekte.

Arbeitselemente und Abfragen

Beim Definieren von Arbeitselementen oder ausführen von Abfragen gelten die folgenden betriebsbedingten Grenzwerte.

Object Begrenzung
Anlagen, die einem Arbeitselement hinzugefügt wurden 100
Anlagengröße 60 MB
Langes Textfeld 1 M Zeichen
Abfrageausführungszeit 30 Sekunden
Abfrageergebnisse 20.000 Elemente
Abfragelänge 32.000 Zeichen
Freigegebene Abfragen unter einem Ordner 999 Abfragen
Einem Arbeitselement zugewiesene Arbeitselementlinks 1\.000
Arbeitselementtags, die einem Arbeitselement zugewiesen sind 100
Überarbeitungen von Arbeitselementen (REST-API) 10.000

Für Updates, die über die REST-API für Azure DevOps Services vorgenommen werden, gilt ein Grenzwert für die Arbeitsaufgabenrevision von 10.000. Dieser Grenzwert schränkt Updates aus der REST-API ein, updates aus dem Webportal sind jedoch nicht betroffen.

Object Begrenzung
Langes Textfeld 1 M Zeichen
Arbeitselementtags, die einem Arbeitselement zugewiesen sind 100
Einem Arbeitselement zugewiesene Arbeitselementlinks 1\.000
Anlagen, die einem Arbeitselement hinzugefügt wurden 100
Anlagengröße 4 MB bis 2 GB
Abfrageausführungszeit 6 Minuten
Abfrageergebnisse 20.000 Elemente
Abfragelänge 32.000 Zeichen
Freigegebene Abfragen unter einem Ordner 999 Abfragen

Die standardmäßige maximale Anlagengröße beträgt 4 MB. Sie können die maximale Größe bis zu 2 GB ändern.

Informationen zur Verbesserung der Abfrageleistung finden Sie unter Leitfaden zum Erstellen von Abfragen mit hoher Leistung.

Backlogs, Boards, Dashboards und Teams

Bei der Arbeit mit Teams, Arbeitselementtags, Backlogs und Boards gelten die folgenden Grenzwerte für die Betriebsanzeige und die Folgenden Objektgrenzwerte.

Benutzeroberfläche Begrenzung
Rückstände 10.000 Arbeitselemente
Boards 1.000 Karten (ohne diese Karten in den StatuskategorienVorgeschlagen und Abgeschlossen)
Task Board 1.000 Aufgaben
Bereichspfade 10.000 pro Organisation
Bereichspfadtiefe 14
Bereichspfade pro Team 300
Iterationspfade 10.000 pro Organisation
Iterationspfadtiefe 14
Iterationspfade pro Team 300
Projektdashboards 500 pro Projekt
Teamdashboards 500 pro Team
Teams 5.000 pro Projekt
Arbeitsaufgabentags 150.000 Tagdefinitionen pro Organisation oder Sammlung
Übermittlungspläne pro Projekt 1\.000
Vorlagen pro Arbeitselementtyp 100

Jedes Backlog kann bis zu 10.000 Arbeitselemente anzeigen. Dies ist ein Limit für die Anzeige des Backlogs, nicht ein Limit für die Anzahl der Arbeitselemente, die Sie definieren können. Wenn Ihr Backlog diesen Grenzwert überschreitet, sollten Sie in Erwägung ziehen, ein Team hinzuzufügen und einige der Arbeitselemente in das Backlog des anderen Teams zu verschieben.

Weitere Hinweise:

  • Abgeschlossene oder geschlossene Arbeitselemente werden nicht auf den Backlogs und Boards angezeigt, sobald ihr Geändertes Datum größer als ein Jahr ist. Sie können diese Elemente weiterhin mithilfe einer Abfrage auflisten. Wenn sie in einem Backlog oder Board angezeigt werden sollen, können Sie eine geringfügige Änderung daran vornehmen, wodurch die Uhr für die Anzeige zurückgesetzt wird.
  • Vermeiden Sie das Schachteln von Backlogelementen desselben Typs. Weitere Informationen finden Sie unter Beheben von Problemen beim Neuanordnen und Schachteln.
  • Vermeiden Sie es, mehreren Teams dieselben Bereichspfade zuzuweisen. Weitere Informationen finden Sie unter Einschränkungen von Kanban-Boardansichten mit mehreren Teams.
  • Standardmäßig können Grenzwerte für Arbeitselemente anfänglich so konfiguriert werden, dass die Werte gesenkt werden.

Bei der Arbeit mit Teams, Arbeitselementtags, Backlogs und Boards gelten die folgenden betriebsbedingten Grenzwerte. Standard- und Höchstgrenzwerte.

Benutzeroberfläche Begrenzung
Rückstände 999 Arbeitselemente
Boards 400 Karten
Dashboards pro Projekt 500
Task Board 800 Arbeitselemente
Teams 5.000 pro Projekt
Arbeitsaufgabentags 150.000 Tagdefinitionen pro Projekt
Vorlagen pro Arbeitselementtyp 100

Jedes Backlog kann bis zu 999 Arbeitselemente anzeigen. Wenn Ihr Backlog diesen Grenzwert überschreitet, sollten Sie in Erwägung ziehen, ein Team hinzuzufügen und einige der Arbeitselemente in das Backlog des anderen Teams zu verschieben.

Weitere Hinweise:

Für das lokale XML-Prozessmodell können Sie die Backlog- und Taskboardgrenzwerte ändern, indem Sie die ProcessConfiguration.xml-Datei bearbeiten. Ausführliche Informationen finden Sie unter Xml-Elementreferenz für die Prozesskonfiguration.

Projekte

Azure DevOps Services jede Organisation auf 1.000 Projekte pro Organisation beschränkt, eine Steigerung gegenüber dem vorherigen Grenzwert von 300 Projekten.

Hinweis

Bei mehr als 300 Projekten können bestimmte Erfahrungen, z. B. das Herstellen einer Verbindung mit einem Projekt aus Visual Studio, möglicherweise beeinträchtigt werden. Für lokale Azure DevOps Server gibt es keine harten Grenzwerte für die Anzahl von Projekten. Sie können jedoch Leistungsprobleme feststellen, wenn sich die Anzahl der Projekte auf 300 annähert. Wenn Sie planen, Ihre lokale Sammlung zu Azure DevOps Services zu migrieren, müssen Sie den Höchstwert von 1.000 Projekten einhalten. Wenn Ihre Sammlung über mehr als 1.000 Projekte verfügt, müssen Sie entweder die Auflistung aufteilen oder ältere Projekte löschen.

Weitere Informationen finden Sie unter Migrieren von Daten von Azure DevOps Server zu Azure DevOps Services.

Prozessanpassung

Für die Anzahl der Objekte, die Sie für einen Prozess definieren können, werden eine Reihe von Grenzwerten festgelegt. Weitere Informationen zu Prozessmodellen finden Sie unter Anpassen der Arbeitsnachverfolgung.

In der folgenden Tabelle ist die maximale Anzahl von Objekten aufgeführt, die Sie für die Prozessmodelle Vererbung und gehostete XML definieren können. Diese stellen zwar harte Grenzwerte dar, können aber auch praktische Grenzwerte gelten.

Object Vererbung Gehostete XML
Anzahl der Prozesse, über die Sie in einer Organisation verfügen können 128 64
Für einen Prozess definierte Arbeitselementtypen 64 64
Für eine Organisation definierte Felder 8192 8192
Für einen Prozess definierte Felder 1024 1024
Felder, die für einen Arbeitselementtyp definiert sind 1024 1024
Für eine Organisation oder Sammlung definierte Auswahllisten 2048 -
Picklistelemente, die für eine Liste definiert sind 2048 2048
Länge des Picklistelements 256 -
Workflowzustände, die für einen Arbeitselementtyp definiert sind 32 16
Für einen Arbeitselementtyp definierte Regeln 1024 1024
Für eine Regel definierte Aktionen 10 10
Für einen Prozess definierte Portfoliobacklogebenen 5 5
Für einen Prozess definierte Kategorien - 32
Globale Listen, die für einen Prozess definiert sind - 256
Listenelemente, die in einer globalen Liste definiert sind - 1024
Größe des Arbeitselementanhangs 60 MB 60 MB

Weitere Einschränkungen und Konformitätsanforderungen des gehosteten XML-Prozessmodells finden Sie unter Anpassen eines Prozesses bei Verwendung von gehostetem XML.

Hinweis

Für das gehostete XML-Prozessmodell können Sie ungefähr 10.000 Elemente für alle globalen Listen definieren, die für alle WITs angegeben sind.

In der folgenden Tabelle ist die maximale Anzahl von Objekten aufgeführt, die Sie für das Vererbungs- und das lokale XML-Prozessmodell definieren können. Diese stellen zwar harte Grenzwerte dar, können aber auch praktische Grenzwerte gelten.

Object Vererbung Lokales XML
Anzahl der Prozesse, über die Sie in einer Organisation verfügen können 64 64
Für einen Prozess definierte Arbeitselementtypen 64 64
Felder, die für eine Auflistung definiert sind 8192 1024
Für einen Prozess definierte Felder 1024 1024
Felder, die für einen Arbeitselementtyp definiert sind 1024 1024
Für eine Sammlung definierte Auswahllisten 1024
Picklistelemente, die für eine Liste definiert sind 2048 2048
Länge des Picklistelements 256
Workflowzustände, die für einen Arbeitselementtyp definiert sind 32 16
Für einen Arbeitselementtyp definierte Regeln 1024 1024
Für einen Prozess definierte Portfoliobacklogebenen 5 5
Für einen Prozess definierte Kategorien 32
Globale Listen, die für einen Prozess definiert sind 256
Listenelemente, die in einer globalen Liste definiert sind 1024

Hinweis

Für das lokale XML-Prozessmodell können Sie ungefähr 10.000 Elemente für alle globalen Listen definieren, die für alle WITs angegeben sind.

In der folgenden Tabelle ist die maximale Anzahl von Objekten aufgeführt, die Sie für das lokale XML-Prozessmodell definieren können. Diese stellen zwar harte Grenzwerte dar, doch können praktische Grenzwerte gelten.

Object Lokales XML
Anzahl der Prozesse, über die Sie in einer Organisation verfügen können 64
Für einen Prozess definierte Arbeitselementtypen 64
Felder, die für eine Auflistung definiert sind 1024
Für einen Prozess definierte Felder 1024
Felder, die für einen Arbeitselementtyp definiert sind 1024
Für eine Sammlung definierte Auswahllisten
Picklistelemente, die für eine Liste definiert sind 2048
Länge des Picklistelements
Workflowzustände, die für einen Arbeitselementtyp definiert sind 16
Für einen Arbeitselementtyp definierte Regeln 1024
Für einen Prozess definierte Portfoliobacklogebenen 5
Für einen Prozess definierte Kategorien 32
Globale Listen, die für einen Prozess definiert sind 256
Listenelemente, die in einer globalen Liste definiert sind 1024
Größe der importierten Prozessvorlage 2 GB

Hinweis

Für das lokale XML-Prozessmodell können Sie ungefähr 10.000 Elemente für alle globalen Listen definieren, die für alle WITs angegeben sind.

Praktische Grenzen

Es wird empfohlen, die folgenden Anleitungen zu berücksichtigen, um Leistungsprobleme zu minimieren.

  • Minimieren Sie die Anzahl der von Ihnen definierten benutzerdefinierten Felder. Alle benutzerdefinierten Felder tragen zur Gesamtsumme bei, die für einen Prozess, eine Sammlung oder eine Organisation zulässig ist. Beachten Sie, dass Sie ein anderes Verhalten für dasselbe Feld in einem anderen WIT angeben können. Das heißt, Sie können verschiedene Regeln, Auswahllisten usw. angeben.
  • Minimieren Sie die Anzahl von Regeln, die Sie für ein WIT definieren. Während Sie mehrere Regeln für ein WIT erstellen können, können sich Additionsregeln negativ auf die Leistung auswirken, wenn ein Benutzer Arbeitselemente hinzufügt und ändert. Wenn Benutzer Arbeitselemente speichern, überprüft das System alle Regeln, die den Feldern für den Arbeitselementtyp zugeordnet sind. Unter bestimmten Bedingungen ist der Regelüberprüfungsausdruck zu komplex, um SQL auszuwerten.
  • Minimieren Sie die Anzahl der von Ihnen definierten benutzerdefinierten WITs.
  • Minimieren Sie die Anzahl der von Ihnen definierten benutzerdefinierten Felder. Alle benutzerdefinierten Felder tragen zur Gesamtsumme bei, die für einen Prozess, eine Sammlung oder eine Organisation zulässig ist. Beachten Sie, dass Sie ein anderes Verhalten für dasselbe Feld in einem anderen WIT angeben können. Das heißt, Sie können verschiedene Regeln, Auswahllisten usw. angeben.
  • Minimieren Sie die Anzahl von Regeln, die Sie für ein WIT definieren. Während Sie mehrere Regeln für ein WIT erstellen können, können sich Additionsregeln negativ auf die Leistung auswirken, wenn ein Benutzer Arbeitselemente hinzufügt und ändert. Wenn Benutzer Arbeitselemente speichern, überprüft das System alle Regeln, die den Feldern für den Arbeitselementtyp zugeordnet sind. Unter bestimmten Bedingungen ist der Regelüberprüfungsausdruck zu komplex, um SQL auszuwerten.
  • Minimieren Sie die Anzahl der von Ihnen definierten benutzerdefinierten WITs.
  • Minimieren Sie die Anzahl der meldebaren Felder, die Sie definieren. Meldebare Felder wirken sich auf die Leistung Ihres Data Warehouses aus.

Hinweis

Überprüfung von Arbeitselementregeln überschreitet SQL-Grenzwerte: Pro Projekt wird ein einzelner SQL-Ausdruck definiert, um Arbeitselemente zu überprüfen, wenn sie erstellt oder aktualisiert werden. Dieser Ausdruck wächst mit der Anzahl von Regeln, die Sie für alle für das Projekt definierten Arbeitselementtypen angeben. Jeder für ein Feld angegebene Verhaltensqualifizierer führt zu einer Erhöhung der Anzahl von Unterausdrücken. Geschachtelte Regeln, Regeln, die nur für einen Übergang gelten oder auf den Wert eines anderen Felds bedingt sind, führen dazu, dass einer IF-Anweisung weitere Bedingungen hinzugefügt werden. Sobald der Ausdruck eine bestimmte Größe oder Komplexität erreicht, kann SQL ihn nicht mehr auswerten und generiert einen Fehler. Wenn Sie einige WITs entfernen oder einige Regeln entfernen, kann der Fehler behoben werden.

Ratenbegrenzungen

Um Kosten zu senken und Skalierbarkeit und Leistung zu verbessern, verwendet Azure DevOps Services, wie viele Software-as-a-Service-Lösungen, mehrinstanzenfähig. Um eine gute Leistung sicherzustellen und die Wahrscheinlichkeit von Ausfällen zu verringern, begrenzt Azure DevOps Services die Ressourcen, die Personen verbrauchen können, und die Anzahl der Anforderungen, die sie an bestimmte Befehle senden können. Wenn diese Grenzwerte überschritten werden, können nachfolgende Anforderungen entweder verzögert oder blockiert werden.

Die meisten Ratenlimits werden durch REST-API-Aufrufe oder nicht optimierte Abfragen erreicht. Weitere Informationen erhalten Sie in den folgenden Artikeln:

Migrations- und Importgrenzwerte

Wenn Sie eine Migration von einer lokalen zu einer Azure DevOps Services festlegen, gibt es möglicherweise mehrere Größenbeschränkungen. Zu diesen Grenzwerten gehören:

  • Die Datenbankgröße liegt über der empfohlenen Größe.
  • Die größte Tabellengröße liegt über der empfohlenen Größe.
  • Die Größe der Datenbankmetadaten liegt über der unterstützten Größe.

Weitere Informationen finden Sie unter Migrieren von Daten von Azure DevOps Server zu Azure DevOps Services und Behandeln von Import- und Migrationsfehlern.