Einschränkungen für Arbeitsnachverfolgung, Prozesse und Projekte

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

In diesem Artikel werden Betriebs- und Objektbeschränkungen definiert, die für Arbeitsverfolgungsvorgänge und Anpassungen der Arbeitsnachverfolgung gelten. Zusätzlich zu den angegebenen harten Grenzwerten für ausgewählte Objekte gelten bestimmte praktische Grenzwerte. Wenn Sie Arbeitsaufgabentypen (Work Item Types, WITs) anpassen, sollten Sie die Grenzwerte berücksichtigen, die für Objekte gelten.

Arbeitsaufgaben und Abfragen

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

Objekt 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
Arbeitsaufgabenlinks, die einer Arbeitsaufgabe zugewiesen sind 1.000
Arbeitselementtags, die einer Arbeitsaufgabe zugewiesen sind 100
Überarbeitungen von Arbeitselementen (REST-API) 10.000
Favoritenabfragen pro Projekt 200 Abfragen

Für Aktualisierungen, die über die REST-API für Azure DevOps Services vorgenommen werden, gilt ein Limit von 10.000 Arbeitselementüberarbeitungen. Dieses Limit begrenzt Aktualisierungen über die REST-API, über das Webportal vorgenommene Aktualisierungen sind jedoch nicht betroffen.

Objekt Begrenzung
Langes Textfeld 1 M Zeichen
Arbeitselementtags, die einer Arbeitsaufgabe zugewiesen sind 100
Arbeitsaufgabenlinks, die einer Arbeitsaufgabe 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
Favoritenabfragen pro Projekt 200 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 Definieren einer Abfrage/bewährter Methoden.

Backlogs, Boards, Dashboards und Teams

Beim Arbeiten mit Teams, Arbeitsaufgabentags, Backlogs und Boards gelten die folgenden Grenzwerte für betriebsfähige Anzeige und Objekte.

User interface (Benutzeroberfläche) Begrenzung
Rückstände 10.000 Arbeitsaufgaben
Boards 1.000 Karte (ausgenommen diese Karte in den Kategorien "Vorgeschlagener und abgeschlossener Workflowstatus"
Task Board 1.000 Vorgänge
Bereichspfade 10.000 pro Projekt
Bereichspfadtiefe 14
Bereichspfade pro Team 300
Iterationspfade 10.000 pro Projekt
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 Arbeitsaufgabentyp 100

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

Zusätzliche Hinweise:

  • Abgeschlossene oder geschlossene Arbeitselemente werden in den Backlogs und auf den Boards nicht angezeigt, sobald deren Änderungsdatum mehr als ein Jahr zurück liegt. 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 daran 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 Schachtelungsproblemen.
  • Vermeiden Sie das Zuweisen derselben Bereichspfade zu mehreren Teams. Weitere Informationen finden Sie unter Einschränkungen von Kanban-Boardansichten mit mehreren Teams.
  • Standardmäßig können Grenzwerte für Arbeitsaufgaben zunächst auf niedrigere Werte konfiguriert werden.

Beim Arbeiten mit Teams, Arbeitsaufgabentags, Backlogs und Boards gelten die folgenden betrieblichen Grenzwerte. Standard- und Maximalgrenzwerte.

User interface (Benutzeroberfläche) Begrenzung
Rückstände 999 Arbeitsaufgaben
Boards 400 Karte
Dashboards pro Projekt 500
Task Board 800 Arbeitsaufgaben
Teams 5.000 pro Projekt
Arbeitsaufgabentags 150.000 Tagdefinitionen pro Projekt
Vorlagen pro Arbeitsaufgabentyp 100

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

Zusätzliche Hinweise:

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

Projekte

Azure DevOps Services schränkt jede Organisation auf 1000 Projekte pro Organisation ein, eine Erhöhung gegenüber dem vorherigen Grenzwert von 300 Projekten.

Hinweis

Über 300 Projekte 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 der Projekte. Es können jedoch Leistungsprobleme auftreten, wenn die Anzahl der Projekte 300 annimmt. Wenn Sie beabsichtigen, Ihre lokale Sammlung zu Azure DevOps Services zu migrieren, müssen Sie die maximale Grenze von 1000 Projekten einhalten. Wenn Ihre Sammlung über mehr als 1000 Projekte verfügt, müssen Sie entweder die Sammlung aufteilen 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 für die Anzahl der Objekte auferlegt, die Sie für einen Prozess definieren können. Informationen zu Prozessmodellen finden Sie unter Anpassen Ihrer Arbeitsverfolgungserfahrung.

Die folgende Tabelle enthält die maximale Anzahl von Objekten, die Sie für die Vererbungs- und gehosteten XML-Prozessmodelle definieren können. Während diese harte Grenzen darstellen, können auch praktische Grenzwerte gelten.

Objekt Vererbung Gehostetes XML
Anzahl der Prozesse, die Sie in einer Organisation haben 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 Arbeitsaufgabentyp definiert sind 1024 1024
Für eine Organisation oder Sammlung definierte Auswahllisten 2048 -
Für eine Liste definierte Auswahllistenelemente 2048 2048
Länge des Auswahlelements 256 -
Für einen Arbeitselementtyp definierte Workflowstatus 32 16
Für einen Arbeitselementtyp definierte Regeln 1024 1024
Für eine Regel definierte Aktionen 10 10
Portfolio-Backlogebenen, die für einen Prozess definiert sind 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
Anlagengröße der Arbeitsaufgabe 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 eine ungefähre Gesamtsumme von 10K-Elementen für alle globalen Listen definieren, die in allen WITs angegeben sind.

Die folgende Tabelle enthält die maximale Anzahl von Objekten, die Sie für die Vererbungs- und lokalen XML-Prozessmodelle definieren können. Während diese harte Grenzen darstellen, können auch praktische Grenzwerte gelten.

Objekt Vererbung Lokales XML
Anzahl der Prozesse, die Sie in einer Organisation haben 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 Arbeitsaufgabentyp definiert sind 1024 1024
Für eine Auflistung definierte Auswahllisten 1024 N/V
Für eine Liste definierte Auswahllistenelemente 2048 2048
Länge des Auswahlelements 256 N/V
Für einen Arbeitselementtyp definierte Workflowstatus 32 16
Für einen Arbeitselementtyp definierte Regeln 1024 1024
Portfolio-Backlogebenen, die für einen Prozess definiert sind 5 5
Für einen Prozess definierte Kategorien N/V 32
Globale Listen, die für einen Prozess definiert sind N/V 256
Listenelemente, die in einer globalen Liste definiert sind N/V 1024

Hinweis

Für das lokale XML-Prozessmodell können Sie eine ungefähre Gesamtsumme von 10K-Elementen für alle globalen Listen definieren, die für alle 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 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 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 Arbeitselementtyp erstellen können, können sich Additionsregeln negativ auf die Leistung auswirken, wenn Benutzer*innen Arbeitselemente hinzufügen und ändern. Wenn Benutzer*innen 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 für die SQL-Auswertung zu komplex.
  • Minimieren Sie die Anzahl der von Ihnen definierten Arbeitselementtypen.
  • Minimieren Sie die Anzahl der benutzerdefinierten Felder, die Sie definieren. 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 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 Arbeitselementtyp erstellen können, können sich Additionsregeln negativ auf die Leistung auswirken, wenn Benutzer*innen Arbeitselemente hinzufügen und ändern. Wenn Benutzer*innen 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 für die SQL-Auswertung zu komplex.
  • Minimieren Sie die Anzahl der von Ihnen definierten Arbeitselementtypen.
  • Minimieren Sie die Anzahl der berichterstattungsfähigen Felder, die Sie definieren. Berichtbare Felder wirken sich auf die Leistung Ihres Data Warehouse aus.

Hinweis

Die Gültigkeitsprüfung von Arbeitsaufgabenregeln überschreitet SQL-Grenzwerte: Ein einzelner SQL-Ausdruck wird pro Projekt definiert, um Arbeitsaufgaben 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 Arbeitsaufgabentypen 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 für 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 hat, kann SQL ihn nicht mehr auswerten und generiert einen Fehler. Wenn Sie einige WITs entfernen oder einige Regeln beseitigen, kann der Fehler behoben werden.

Ratenbegrenzungen

Um Kosten zu senken und die Skalierbarkeit und Leistung zu verbessern, verwendet Azure DevOps Services wie viele Software-as-a-Service-Lösungen mehrinstanzenfähige Mandanten. Um eine gute Leistung sicherzustellen und die Wahrscheinlichkeit von Ausfällen zu verringern, schränkt Azure DevOps Services die Ressourcen ein, die einzelpersonen 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 Ratengrenzwerte 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 der Migration von lokalen zu Azure DevOps Services gibt es mehrere Größenbeschränkungen, die möglicherweise auftreten. Diese Grenzwerte umfassen Folgendes:

  • Die Datenbankgröße liegt oberhalb 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 Zur Problembehandlung bei Import- und Migrationsfehlern.