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 definiert, die für Arbeitsverfolgungsvorgänge und Anpassungen der Arbeitsnachverfolgung platziert wurden. Zusätzlich zu den angegebenen harten Grenzwerten für ausgewählte Objekte gelten bestimmte praktische Grenzwerte. Wenn Sie Arbeitsaufgabentypen (WITs) anpassen, sollten Sie die Grenzwerte berücksichtigen, die auf Objekten platziert werden.

Arbeitselemente und Abfragen

Beim Definieren von Arbeitselementen oder Ausführen von Abfragen gelten die folgenden betrieblichen Grenzwerte.

Object Begrenzung
Anlagen, die einer Arbeitsaufgabe 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
Arbeitselementlinks, die einem Arbeitselement zugewiesen sind 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, wird eine Überarbeitungsgrenze von 10.000 Arbeitselementen wirksam. 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
Arbeitselementlinks, die einem Arbeitselement zugewiesen sind 1\.000
Anlagen, die einer Arbeitsaufgabe 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 Anleitungen zum Erstellen von leistungsstarken Abfragen.

Backlogs, Boards, Dashboards und Teams

Bei der Arbeit mit Teams, Arbeitsaufgabentags, Backlogs und Boards gelten die folgenden Betriebsanzeige- und Objektbeschränkungen.

Benutzeroberfläche Begrenzung
Rückstände 10.000 Arbeitselemente
Boards 1.000 Karten (ausgenommen diese Karten in den Kategorien "Vorgeschlagener und abgeschlossener Workflowstatus")
Task Board 1.000 Vorgänge
Bereichspfade 10.000 pro Organisation
Bereichspfadtiefe 14
Bereichspfade pro Team 300
Iterationspfade 10.000 pro Organisation
Iterationspfadtiefe 14
Iterationspfade pro Team 300
Dashboards pro Projekt 500
Teams 5.000 pro Organisation
Arbeitsaufgabentags 150.000 Tagdefinitionen pro Organisation oder Sammlung
Übermittlungspläne pro Projekt 1\.000

Jeder 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 möglicherweise ein Team hinzufügen und einige der Arbeitsaufgaben in den Backlog des anderen Teams verschieben.

Weitere Hinweise:

  • Abgeschlossene oder geschlossene Arbeitselemente werden nicht auf den Backlogs und Tafeln angezeigt, sobald ihr geändertes Datum größer als ein Jahr ist. Sie können diese Elemente weiterhin mithilfe einer Abfrage auflisten. Wenn sie auf einem Backlog oder Board angezeigt werden sollen, können Sie eine geringfügige Änderung an ihnen vornehmen, die die Uhr für die Anzeige zurücksetzt.
  • Vermeiden Sie das Verschachteln von Backlogelementen desselben Typs. Weitere Informationen finden Sie unter Beheben von Neuanordnungs- und Verschachtelungsproblemen.
  • Vermeiden Sie das Zuweisen derselben Bereichspfade zu mehreren Teams. Weitere Informationen finden Sie unter Einschränkungen von Kanban-Ansichten mit mehreren Teams.
  • Standardmäßig können Arbeitsaufgabenbeschränkungen anfänglich auf niedrigere Werte konfiguriert werden.

Bei der Arbeit mit Teams, Arbeitsaufgabentags, Backlogs und Boards gelten die folgenden betrieblichen 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

Jeder Backlog kann bis zu 999 Arbeitselemente anzeigen. Wenn Ihr Backlog diesen Grenzwert überschreitet, sollten Sie möglicherweise ein Team hinzufügen und einige der Arbeitselemente zum Backlog des anderen Teams verschieben.

Weitere Hinweise:

Für das lokale XML-Prozessmodell können Sie den Backlog- und Taskboardbeschränkungen ändern, indem Sie die ProcessConfiguration.xml-Datei bearbeiten. Ausführliche Informationen finden Sie unter Prozesskonfigurations-XML-Elementreferenz.

Projekte

Azure DevOps Services beschränkt jede Organisation auf 1000 Projekte pro Organisation, eine Erhöhung über die vorherige Grenze von 300 Projekten.

Hinweis

Über 300 Projekte können bestimmte Erfahrungen, z. B. die Verbindung mit einem Projekt aus Visual Studio, möglicherweise beeinträchtigt werden. Für lokale Azure DevOps Server gibt es keine harten Grenzen für die Anzahl der Projekte. Sie können jedoch Leistungsprobleme finden, wenn die Anzahl der Projekte 300 angibt. Wenn Sie planen, Ihre lokale Auflistung zu Azure DevOps Services zu migrieren, müssen Sie die maximale Grenze von 1000 Projekten beobachten. Wenn Ihre Auflistung über mehr als 1000 Projekte verfügt, müssen Sie entweder die Auflistung teilen oder ältere Projekte löschen.

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

Prozessanpassung

Eine Reihe von Grenzwerten wird auf die Anzahl der Objekte festgelegt, die Sie für einen Prozess definieren können. Informationen zu Prozessmodellen finden Sie unter Anpassen Ihrer Arbeitsverfolgungserfahrung.

In der folgenden Tabelle sind die maximale Anzahl von Objekten aufgeführt, die Sie für die Vererbungs- und gehosteten XML-Prozessmodelle definieren können. Dies stellt zwar harte Grenzwerte dar, aber auch praktische Grenzwerte gelten.

Object Vererbung Gehostete XML
Anzahl der Prozesse, die Sie in einer Organisation haben können 128 64
Arbeitselementtypen, die für einen Prozess definiert sind 64 64
Für eine Organisation definierte Felder 8192 8192
Felder, die für einen Prozess definiert sind 1024 1024
Felder, die für einen Arbeitselementtyp definiert sind 1024 1024
Auswahllisten, die für eine Organisation oder Auflistung definiert sind 2048 -
Auswahllistenelemente, die für eine Liste definiert sind 2048 2048
Länge des Auswahllistenelements 256 -
Workflowzustände, die für einen Arbeitselementtyp definiert sind 32 16
Regeln, die für einen Arbeitselementtyp definiert sind 1024 1024
Für eine Regel definierte Aktionen 10 10
Für einen Prozess definierte Portfolio-Backlog-Ebenen 5 5
Kategorien, die für einen Prozess definiert sind - 32
Globale Listen, die für einen Prozess definiert sind - 256
Listenelemente, die in einer globalen Liste definiert sind - 1024
Größe der Arbeitselementanlage 60 MB 60 MB

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

Hinweis

Für das Gehostete XML-Prozessmodell können Sie ungefähr 10K-Elemente für alle globalen Listen definieren, die in allen WITs angegeben sind.

In der folgenden Tabelle sind die maximale Anzahl von Objekten aufgeführt, die Sie für die Vererbungs- und lokalen XML-Prozessmodelle definieren können. Dies stellt zwar harte Grenzwerte dar, aber auch praktische Grenzwerte gelten.

Object Vererbung Lokales XML
Anzahl der Prozesse, die Sie in einer Organisation haben können 64 64
Arbeitselementtypen, die für einen Prozess definiert sind 64 64
Felder, die für eine Auflistung definiert sind 8192 1024
Felder, die für einen Prozess definiert sind 1024 1024
Felder, die für einen Arbeitselementtyp definiert sind 1024 1024
Auswahllisten, die für eine Auflistung definiert sind 1024
Auswahllistenelemente, die für eine Liste definiert sind 2048 2048
Länge des Auswahllistenelements 256
Workflowzustände, die für einen Arbeitselementtyp definiert sind 32 16
Regeln, die für einen Arbeitselementtyp definiert sind 1024 1024
Für einen Prozess definierte Portfolio-Backlog-Ebenen 5 5
Kategorien, die für einen Prozess definiert sind 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 10K-Elemente für alle globalen Listen definieren, die in allen WITs angegeben sind.

In der folgenden Tabelle sind die maximale Anzahl von Objekten aufgeführt, die Sie für das lokale XML-Prozessmodell definieren können. Während diese harte Grenzen darstellen, können praktische Grenzwerte gelten.

Object Lokales XML
Anzahl der Prozesse, die Sie in einer Organisation haben können 64
Arbeitselementtypen, die für einen Prozess definiert sind 64
Felder, die für eine Auflistung definiert sind 1024
Felder, die für einen Prozess definiert sind 1024
Felder, die für einen Arbeitselementtyp definiert sind 1024
Auswahllisten, die für eine Auflistung definiert sind
Auswahllistenelemente, die für eine Liste definiert sind 2048
Länge des Auswahllistenelements
Workflowzustände, die für einen Arbeitselementtyp definiert sind 16
Regeln, die für einen Arbeitselementtyp definiert sind 1024
Für einen Prozess definierte Portfolio-Backlog-Ebenen 5
Kategorien, die für einen Prozess definiert sind 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 10K-Elemente für alle globalen Listen definieren, die in allen WITs angegeben sind.

Praktische Grenzwerte

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

  • Minimieren Sie die Anzahl der benutzerdefinierten Felder, die Sie definieren. Alle benutzerdefinierten Felder tragen zur Summe bei, die für einen Prozess, eine Auflistung oder eine Organisation zulässig ist. Beachten Sie, dass Sie ein anderes Verhalten für das gleiche Feld in einem anderen WIT angeben können. Das heißt, Sie können verschiedene Regeln, Auswahllisten und vieles mehr angeben.
  • Minimieren Sie die Anzahl der Regeln, die Sie für ein WIT definieren. Während Sie mehrere Regeln für ein WIT erstellen können, können zusätzliche Regeln die Leistung negativ beeinflussen, 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, damit SQL ausgewertet werden kann.
  • Minimieren Sie die Anzahl der benutzerdefinierten WITs, die Sie definieren.
  • Minimieren Sie die Anzahl der benutzerdefinierten Felder, die Sie definieren. Alle benutzerdefinierten Felder tragen zur Summe bei, die für einen Prozess, eine Auflistung oder eine Organisation zulässig ist. Beachten Sie, dass Sie ein anderes Verhalten für das gleiche Feld in einem anderen WIT angeben können. Das heißt, Sie können verschiedene Regeln, Auswahllisten und vieles mehr angeben.
  • Minimieren Sie die Anzahl der Regeln, die Sie für ein WIT definieren. Während Sie mehrere Regeln für ein WIT erstellen können, können zusätzliche Regeln die Leistung negativ beeinflussen, 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, damit SQL ausgewertet werden kann.
  • Minimieren Sie die Anzahl der benutzerdefinierten WITs, die Sie definieren.
  • Minimieren Sie die Anzahl der berichtsfähigen Felder, die Sie definieren. Berichtbare Felder wirken sich auf die Leistung Ihres Datenlagers aus.

Hinweis

Die Überprüfung der Arbeitselementregeln überschreitet SQL-Grenzwerte: Ein einzelner SQL-Ausdruck wird pro Projekt definiert, um Arbeitselemente zu überprüfen, wenn sie erstellt oder aktualisiert werden. Dieser Ausdruck wächst mit der Anzahl der 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 der Unterausdrücke. Geschachtelte Regeln, regeln, die nur für einen Übergang oder eine Bedingung für den Wert eines anderen Felds gelten, verursachen mehr Bedingungen, die einer IF-Anweisung hinzugefügt werden. Sobald der Ausdruck eine bestimmte Größe oder Komplexität erreicht hat, kann SQL es nicht mehr auswerten und generiert einen Fehler. Das Entfernen einiger WITs oder die Beseitigung einiger Regeln kann den Fehler beheben.

Ratenbegrenzungen

Um Kosten zu reduzieren und die Skalierbarkeit und Leistung zu verbessern, Azure DevOps Services, wie viele Software-as-a-Service-Lösungen, verwendet mehrstufige Mandanten. Um eine gute Leistung zu gewährleisten und die Wahrscheinlichkeit von Ausfällen zu verringern, Azure DevOps Services die Ressourcen, die einzelne Personen nutzen können, und die Anzahl der Anforderungen, die sie an bestimmte Befehle vornehmen können. Wenn diese Grenzwerte überschritten werden, können nachfolgende Anforderungen entweder verzögert oder blockiert werden.

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

Migrieren und Importieren von Grenzwerten

Bei der Bestimmung, von lokalen zu Azure DevOps Services zu migrieren, gibt es mehrere Größenbeschränkungen, die möglicherweise auftreten. Diese Grenzwerte umfassen:

  • Die Datenbankgröße ist über der empfohlenen Größe.
  • Die größte Tabellengröße ist ü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 Problembehandlung bei Import- und Migrationsfehlern.