Limieten voor processen, projecten en het bijhouden van werk

  • Artikel

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

In dit artikel worden operationele en objectlimieten gedefinieerd die zijn geplaatst voor werktraceringsbewerkingen en aanpassingen voor het bijhouden van werk. Naast de opgegeven vaste limieten voor bepaalde objecten zijn bepaalde praktische limieten van toepassing. Wanneer u werkitemstypen (WIT's) aanpast, moet u rekening houden met de limieten voor objecten.

Werkitems en query's

Bij het definiëren van werkitems of het uitvoeren van query's zijn de volgende operationele limieten van toepassing.

Object Grenswaarde
Bijlagen toegevoegd aan een werkitem 100
Bijlagegrootte 60 MB
Lang tekstveld 1 M tekens
Uitvoeringstijd van query's 30 seconden
Queryresultaten 20.000 items
Querylengte 32.000 tekens
Gedeelde query's onder een map 999 query's
Koppelingen naar werkitems die zijn toegewezen aan een werkitem 1.000
Tags voor werkitems die zijn toegewezen aan een werkitem 100
Revisies van werkitems (REST API) 10,000
Favoriete query's per project 200 query's

Een revisielimiet voor werkitems van 10.000 is van kracht voor updates die zijn gemaakt via de REST API voor Azure DevOps Services. Deze limiet beperkt updates van de REST API, maar updates van de webportal worden niet beïnvloed.

Object Grenswaarde
Lang tekstveld 1 M tekens
Tags voor werkitems die zijn toegewezen aan een werkitem 100
Koppelingen naar werkitems die zijn toegewezen aan een werkitem 1.000
Bijlagen toegevoegd aan een werkitem 100
Bijlagegrootte 4 MB tot 2 GB
Uitvoeringstijd van query's 6 minuten
Queryresultaten 20.000 items
Querylengte 32.000 tekens
Gedeelde query's onder een map 999 query's
Favoriete query's per project 200 query's

De standaard maximale bijlagegrootte is 4 MB. U kunt de maximale grootte wijzigen tot 2 GB.

Zie Een query/best practices definiëren om de prestaties van query's te verbeteren.

Achterstanden, borden, dashboards en teams

Wanneer u werkt met teams, werkitemtags, achterstanden en borden, zijn de volgende operationele weergave- en objectlimieten van toepassing.

Gebruikersinterface Grenswaarde
Achterstanden 10.000 werkitems
Boards 1000 kaarten (met uitzondering van deze kaarten in de categorieën Voorgestelde en Voltooide werkstroomstatus)
Taskboard 1000 taken
Gebiedspaden 10.000 per project
Diepte van gebiedspad 14
Gebiedspaden per team 300
Iteratiepaden 10.000 per project
Diepte van iteratiepad 14
Iteratiepaden per team 300
Projectdashboards 500 per project
Teamdashboards 500 per team
Teams 5.000 per project
Tags voor werkitems 150.000 tagdefinities per organisatie of verzameling
Leveringsplannen per project 1.000
Sjablonen per werkitemtype 100

Elke achterstand kan maximaal 10.000 werkitems weergeven. Dit is een limiet voor wat de achterstand kan weergeven, niet een limiet voor het aantal werkitems dat u kunt definiëren. Als uw achterstand deze limiet overschrijdt, kunt u overwegen een team toe te voegen en enkele werkitems naar de achterstand van het andere team te verplaatsen.

Aanvullende opmerkingen:

  • Voltooide of gesloten werkitems worden niet weergegeven op de achterstanden en borden zodra de gewijzigde datum groter is dan een jaar oud. U kunt deze items nog steeds weergeven met behulp van een query. Als u wilt dat ze worden weergegeven in een achterstand of bord, kunt u een kleine wijziging aanbrengen in deze wijzigingen, waardoor de klok opnieuw wordt ingesteld voor weergave.
  • Vermijd het nesten van backlogitems van hetzelfde type. Zie Problemen met opnieuw ordenen en nesten oplossen voor meer informatie.
  • Vermijd het toewijzen van dezelfde gebiedspaden aan meer dan één team. Zie Beperkingen van kanbanbordweergaven met meerdere teams voor meer informatie.
  • Standaard kunnen werkitemlimieten in eerste instantie worden geconfigureerd voor lagere waarden.

Bij het werken met teams, werkitemtags, achterstanden en borden zijn de volgende operationele limieten van toepassing. Standaard- en maximumlimieten.

Gebruikersinterface Grenswaarde
Achterstanden 999 werkitems
Boards 400 kaarten
Dashboards per project 500
Taskboard 800 werkitems
Teams 5.000 per project
Tags voor werkitems 150.000 tagdefinities per project
Sjablonen per werkitemtype 100

Elke achterstand kan maximaal 999 werkitems weergeven. Als uw achterstand deze limiet overschrijdt, kunt u overwegen een team toe te voegen en enkele werkitems naar de achterstand van het andere team te verplaatsen.

Aanvullende opmerkingen:

  • Vermijd het nesten van backlogitems van hetzelfde type. Zie Problemen met opnieuw ordenen en nesten oplossen voor meer informatie.
  • Vermijd het toewijzen van dezelfde gebiedspaden aan meer dan één team. Zie Beperkingen van kanbanbordweergaven met meerdere teams voor meer informatie.

Voor het on-premises XML-procesmodel kunt u de achterstands- en taskboardlimieten wijzigen door het ProcessConfiguration.xml bestand te bewerken. Zie De verwijzing naar xml-element voor procesconfiguratie voor meer informatie.

Projecten

Azure DevOps Services beperkt elke organisatie tot 1000 projecten per organisatie, een toename ten opzichte van de vorige limiet van 300 projecten.

Notitie

Boven de 300 projecten kunnen bepaalde ervaringen, zoals het maken van verbinding met een project vanuit Visual Studio, afnemen. Voor on-premises Azure DevOps Server gelden geen vaste limieten voor het aantal projecten. U kunt echter prestatieproblemen vinden als het aantal projecten 300 nadert. Als u van plan bent om uw on-premises verzameling te migreren naar Azure DevOps Services, moet u de maximumlimiet van 1000 projecten observeren. Als uw verzameling meer dan 1000 projecten heeft, moet u de verzameling splitsen of oudere projecten verwijderen.

Zie Gegevens migreren van Azure DevOps Server naar Azure DevOps Services voor meer informatie.

Procesaanpassing

Er worden een aantal limieten opgelegd aan het aantal objecten dat u voor een proces kunt definiëren. Zie Uw ervaring voor het bijhouden van werk aanpassen voor meer informatie over procesmodellen.

De volgende tabel bevat het maximum aantal objecten dat u kunt definiëren voor de overname- en gehoste XML-procesmodellen. Hoewel deze harde limieten vertegenwoordigen, kunnen ook praktische limieten van toepassing zijn.

Object Overname Gehoste XML
Aantal processen dat u in een organisatie kunt hebben 128 64
De werkitemtypen die zijn gedefinieerd voor een proces 64 64
Velden die zijn gedefinieerd voor een organisatie 8192 8192
Gedefinieerde velden voor een proces 1024 1024
Velden gedefinieerd voor een werkitemtype 1024 1024
Selectielijsten gedefinieerd voor een organisatie of verzameling 2048 -
Selectielijstitems gedefinieerd voor een lijst 2048 2048
Lengte van selectielijstitem 256 -
De werkstroomstatussen die zijn gedefinieerd voor een type werkitem 32 16
De regels die zijn gedefinieerd voor een type werkitem 1024 1024
Acties die zijn gedefinieerd voor een regel 10 10
Portfolioachterstandsniveaus gedefinieerd voor een proces 5 5
Categorieën die zijn gedefinieerd voor een proces - 32
Globale lijsten die zijn gedefinieerd voor een proces - 256
Lijstitems gedefinieerd in een globale lijst - 1024
Grootte van bijlage werkitem 60 MB 60 MB

Zie Een proces aanpassen bij het gebruik van gehoste XML voor aanvullende beperkingen en nalevingsvereisten van het model voor gehoste XML.

Notitie

Voor het model voor het gehoste XML-proces kunt u een totaal van 10.000 items definiëren voor alle globale lijsten die zijn opgegeven in alle WIT's.

De volgende tabel bevat het maximum aantal objecten dat u kunt definiëren voor de overname- en on-premises XML-procesmodellen. Hoewel deze harde limieten vertegenwoordigen, kunnen ook praktische limieten van toepassing zijn.

Object Overname On-premises XML
Aantal processen dat u in een organisatie kunt hebben 64 64
De werkitemtypen die zijn gedefinieerd voor een proces 64 64
Velden gedefinieerd voor een verzameling 8192 1024
Gedefinieerde velden voor een proces 1024 1024
Velden gedefinieerd voor een werkitemtype 1024 1024
Selectielijsten gedefinieerd voor een verzameling 1024 N.v.t.
Selectielijstitems gedefinieerd voor een lijst 2048 2048
Lengte van selectielijstitem 256 N.v.t.
De werkstroomstatussen die zijn gedefinieerd voor een type werkitem 32 16
De regels die zijn gedefinieerd voor een type werkitem 1024 1024
Portfolioachterstandsniveaus gedefinieerd voor een proces 5 5
Categorieën die zijn gedefinieerd voor een proces N.v.t. 32
Globale lijsten die zijn gedefinieerd voor een proces N.v.t. 256
Lijstitems gedefinieerd in een globale lijst N.v.t. 1024

Notitie

Voor het on-premises XML-procesmodel kunt u een totaal van 10.000 items definiëren voor alle globale lijsten die zijn opgegeven in alle WIT's.

Praktische limieten

We raden u aan de volgende richtlijnen te overwegen om prestatieproblemen te minimaliseren.

  • Minimaliseer het aantal aangepaste velden dat u definieert. Alle aangepaste velden dragen bij aan het totaal dat is toegestaan voor een proces, verzameling of organisatie. Houd er rekening mee dat u voor hetzelfde veld in een andere WIT een ander gedrag kunt opgeven. Dat wil gezegd, u kunt verschillende regels, selectielijsten en meer opgeven.
  • Minimaliseer het aantal regels dat u definieert voor een WIT. Hoewel u meerdere regels voor een WIT kunt maken, kunnen toevoegingsregels een negatieve invloed hebben op de prestaties wanneer een gebruiker werkitems toevoegt en wijzigt. Wanneer gebruikers werkitems opslaan, valideert het systeem alle regels die zijn gekoppeld aan de velden voor het type werkitem. Onder bepaalde omstandigheden is de expressie voor regelvalidatie te complex om door SQL te kunnen worden geëvalueerd.
  • Beperk het aantal aangepaste WIT's dat u definieert.
  • Minimaliseer het aantal aangepaste velden dat u definieert. Alle aangepaste velden dragen bij aan het totaal dat is toegestaan voor een proces, verzameling of organisatie. Houd er rekening mee dat u voor hetzelfde veld in een andere WIT een ander gedrag kunt opgeven. Dat wil gezegd, u kunt verschillende regels, selectielijsten en meer opgeven.
  • Minimaliseer het aantal regels dat u definieert voor een WIT. Hoewel u meerdere regels voor een WIT kunt maken, kunnen toevoegingsregels een negatieve invloed hebben op de prestaties wanneer een gebruiker werkitems toevoegt en wijzigt. Wanneer gebruikers werkitems opslaan, valideert het systeem alle regels die zijn gekoppeld aan de velden voor het type werkitem. Onder bepaalde omstandigheden is de expressie voor regelvalidatie te complex om door SQL te kunnen worden geëvalueerd.
  • Beperk het aantal aangepaste WIT's dat u definieert.
  • Minimaliseer het aantal rapportbare velden dat u definieert. Rapportbare velden zijn van invloed op de prestaties van uw datawarehouse.

Notitie

Validatie van werkitemregels overschrijdt SQL-limieten: er wordt per project één SQL-expressie gedefinieerd om werkitems te valideren wanneer ze worden gemaakt of bijgewerkt. Deze expressie groeit met het aantal regels dat u opgeeft voor alle typen werkitems die zijn gedefinieerd voor het project. Elke gedragskwalificatie die is opgegeven voor een veld resulteert in een toename van het aantal subexpressies. Geneste regels, regels die alleen van toepassing zijn op een overgang of voorwaarde voor de waarde van een ander veld, zorgen ervoor dat er meer voorwaarden worden toegevoegd aan een IF-instructie. Zodra de expressie een bepaalde grootte of complexiteit heeft bereikt, kan SQL deze niet meer evalueren en wordt er een fout gegenereerd. Als u sommige WIT's verwijdert of bepaalde regels verwijdert, kunt u de fout oplossen.

Frequentielimieten

Azure DevOps Services, zoals veel Software-as-a-Service-oplossingen, maakt gebruik van multitenancy om de kosten te verlagen en de schaalbaarheid en prestaties te verbeteren. Om goede prestaties te garanderen en de kans op storingen te verminderen, beperkt Azure DevOps Services de resources die personen kunnen verbruiken en het aantal aanvragen dat ze kunnen indienen bij bepaalde opdrachten. Wanneer deze limieten worden overschreden, kunnen volgende aanvragen worden vertraagd of geblokkeerd.

De meeste frequentielimieten worden bereikt via REST API-aanroepen of niet-geoptimaliseerde query's. Zie de volgende artikelen voor meer informatie:

Limieten voor migreren en importeren

Bij het bepalen van de migratie van on-premises naar Azure DevOps Services zijn er verschillende groottelimieten die u kunt tegenkomen. Deze limieten zijn onder andere:

  • Databasegrootte ligt boven de aanbevolen grootte
  • De grootste tabelgrootte ligt boven de aanbevolen grootte
  • De grootte van de metagegevens van de database ligt boven de ondersteunde grootte

Zie Gegevens migreren van Azure DevOps Server naar Azure DevOps Services en problemen met importeren en migratie oplossen voor meer informatie.