Limieten voor processen, projecten en het bijhouden van werk
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 |
Werkitemtags | 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 weergaven voor 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 |
Werkitemtags | 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 weergaven voor 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 |
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. Raadpleeg voor meer informatie de volgende artikelen:
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 import- en migratiefouten oplossen voor meer informatie.
Verwante artikelen:
Verwante resources
Feedback
https://aka.ms/ContentUserFeedback.
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie:Feedback verzenden en weergeven voor