Limiti di progetti, processi e rilevamento del lavoro
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Questo articolo definisce i limiti operativi e degli oggetti posti per le operazioni di rilevamento del lavoro e la personalizzazione del rilevamento del lavoro. Oltre ai limiti rigidi specificati per oggetti specifici, si applicano alcuni limiti pratici. Quando si personalizzano i tipi di elementi di lavoro (WIT), considerare i limiti inseriti sugli oggetti.
Elementi di lavoro e query
Quando si definiscono elementi di lavoro o si eseguono query, tenere presenti i limiti operativi seguenti:
| Object | Limite |
|---|---|
| Allegati aggiunti a un elemento di lavoro | 100 |
| Dimensioni allegati | 60 MB |
| Campo di testo lungo | 1-M caratteri |
| Tempo di esecuzione della query | 30 secondi |
| Risultati query | 20.000 elementi |
| Lunghezza query | 32.000 caratteri |
| Query condivise in una cartella | 999 query |
| Collegamenti elemento di lavoro assegnati a un elemento di lavoro | 1.000 |
| Tag elemento di lavoro assegnati a un elemento di lavoro | 100 |
| Revisioni degli elementi di lavoro (API REST) | 10,000 |
| Query preferite per progetto | 200 query |
L'API REST per Azure DevOps Services applica un limite di revisione degli elementi di lavoro di 10.000 aggiornamenti. Questo limite limita gli aggiornamenti eseguiti tramite l'API REST, ma gli aggiornamenti dal portale Web non sono interessati.
| Object | Limite |
|---|---|
| Campo di testo lungo | 1-M caratteri |
| Tag elemento di lavoro assegnati a un elemento di lavoro | 100 |
| Collegamenti elemento di lavoro assegnati a un elemento di lavoro | 1.000 |
| Allegati aggiunti a un elemento di lavoro | 100 |
| Dimensioni allegati | Da 4 MB a 2 GB |
| Tempo di esecuzione della query | 6 minuti |
| Risultati query | 20.000 elementi |
| Lunghezza query | 32.000 caratteri |
| Query condivise in una cartella | 999 query |
| Query preferite per progetto | 200 query |
La dimensione massima predefinita degli allegati è 4 MB. È possibile modificare le dimensioni massime fino a 2 GB.
Per migliorare le prestazioni delle query, vedere Definire una query o procedure consigliate.
Backlog, bacheche, dashboard e team
Quando si lavora con team, tag degli elementi di lavoro, backlog e bacheche, si applicano i limiti di visualizzazione e oggetti operativi seguenti.
| Interfaccia utente | Limite |
|---|---|
| Backlog | 10.000 elementi di lavoro |
| Boards | 1.000 schede (escluse le schede nelle categorie di stato proposte e completate del flusso di lavoro) |
| Tabellone attività | 1.000 attività |
| Percorsi dell'area | 10.000 per progetto |
| Profondità percorso area | 14 |
| Percorsi di area per team | 300 |
| Percorsi di iterazione | 10.000 per progetto |
| Profondità percorso iterazione | 14 |
| Percorsi di iterazione per team | 300 |
| Dashboard del progetto | 500 per progetto. Accessibile a livello di progetto e chiunque abbia accesso al progetto può usare. |
| Dashboard del team | 500 per squadra. Specifico del team e usato per tenere traccia di metriche e dati specifici del team. |
| Teams | 5.000 per progetto |
| Tag dell'elemento di lavoro | 150.000 definizioni di tag per organizzazione o raccolta |
| Piani di recapito per progetto | 1.000 |
| Modelli per tipo di elemento di lavoro | 100 |
Ogni backlog può visualizzare fino a 10.000 elementi di lavoro. Questo limite si applica a ciò che il backlog può visualizzare, non al numero di elementi di lavoro che è possibile definire, perché non esiste alcun limite specifico. Se il backlog supera questo limite, prendere in considerazione l'aggiunta di un team e lo spostamento di alcuni elementi di lavoro nel backlog del nuovo team.
Suggerimento
Se si stanno raggiungendo i limiti dei dashboard, vedere la procedura seguente per gestire e pulire i dashboard:
- Esaminare l'utilizzo: identificare i dashboard che non sono più in uso o sono duplicati. È possibile eseguire questa operazione controllando l'ultima data di accesso o consultando i membri del team.
- Consolidare i dashboard: combinare dashboard simili per ridurre il numero totale. A tale scopo, è possibile aggiungere più widget a un singolo dashboard.
- Archiviare i dashboard precedenti: se alcuni dashboard non sono più necessari, ma si vogliono mantenere i dati, è consigliabile esportare i dati e archiviare i dashboard.
- Usare la funzionalità Rilevamento limiti oggetti: offre visibilità in tempo reale sull'utilizzo delle risorse, inclusi i dashboard. Questa funzionalità consente di gestire in modo proattivo i limiti ed evitare potenziali problemi.
Altre note:
- Gli elementi di lavoro completati o chiusi non vengono visualizzati nei backlog e nelle lavagne dopo che la data modificata è precedente a un anno. È comunque possibile elencare questi elementi usando una query. Per renderli visualizzati su un backlog o una lavagna, apportare una modifica secondaria per reimpostare l'orologio dello schermo.
- Evitare di annidare elementi di backlog dello stesso tipo. Per altre informazioni, vedere Risolvere i problemi di riordinamento e annidamento.
- Evitare di assegnare gli stessi percorsi di area a più team. Per altre informazioni, vedere Limitazioni delle visualizzazioni della bacheca di più team.
- Per impostazione predefinita, i limiti degli elementi di lavoro potrebbero essere impostati inizialmente su valori inferiori.
Quando si lavora con i team, i tag degli elementi di lavoro, i backlog e le bacheche, si applicano i limiti operativi seguenti. Limiti predefiniti e massimi.
| Interfaccia utente | Limite |
|---|---|
| Backlog | 999 elementi di lavoro |
| Boards | 400 carte |
| Dashboard per progetto | 500 |
| Tabellone attività | 800 elementi di lavoro |
| Teams | 5.000 per progetto |
| Tag dell'elemento di lavoro | 150.000 definizioni di tag per progetto |
| Modelli per tipo di elemento di lavoro | 100 |
Ogni backlog può visualizzare fino a 999 elementi di lavoro. Se il backlog supera questo limite, prendere in considerazione la creazione di un team e lo spostamento di alcuni elementi di lavoro nel backlog del nuovo team.
Altre note:
- Evitare di annidare elementi di backlog dello stesso tipo. Per altre informazioni, vedere Risolvere i problemi di riordinamento e annidamento.
- Evitare di assegnare gli stessi percorsi di area a più team. Per altre informazioni, vedere Limitazioni delle visualizzazioni della bacheca di più team.
Per il modello di processo XML locale, è possibile modificare i limiti di backlog e Taskboard modificando il ProcessConfiguration.xml file. Per informazioni dettagliate, vedere Informazioni di riferimento sull'elemento XML di configurazione del processo.
Progetti
Azure DevOps Services limita ogni organizzazione a 1.000 progetti per organizzazione, un aumento rispetto al limite precedente di 300 progetti.
Nota
Oltre 300 progetti, alcune esperienze, ad esempio la connessione a un progetto da Visual Studio, potrebbero peggiorare. Per Azure DevOps Server locale, non esistono limiti rigidi, ma possono verificarsi problemi di prestazioni quando il numero di progetti si avvicina a 300. Quando si esegue la migrazione ad Azure DevOps Services, osservare il limite massimo di 1.000 progetti. Se la raccolta supera questo limite, suddividere la raccolta o eliminare progetti meno recenti.
Per altre informazioni, vedere Eseguire la migrazione dei dati da Azure DevOps Server ad Azure DevOps Services.
Personalizzazione dei processi
Molti limiti vengono imposti al numero di oggetti che è possibile definire per un processo. Per altre informazioni, vedere Personalizzare l'esperienza di rilevamento del lavoro.
La tabella seguente elenca il numero massimo di oggetti che è possibile definire per i modelli di processo Di ereditarietà e XML ospitati. Anche se questi limiti sono limiti rigidi, potrebbero essere applicati anche limiti pratici.
| Object | Ereditarietà | XML ospitato |
|---|---|---|
| Numero di processi che è possibile avere in un'organizzazione | 128 | 64 |
| Tipi di elementi di lavoro definiti per un processo | 64 | 64 |
| Campi definiti per un'organizzazione | 8192 | 8192 |
| Campi definiti per un processo | 1024 | 1024 |
| Campi definiti per un tipo di elemento di lavoro | 1024 | 1024 |
| Elenchi di selezione definiti per un'organizzazione o una raccolta | 2048 | - |
| Elementi elenco di selezione definiti per un elenco | 2048 | 2048 |
| Lunghezza carattere elemento elenco a discesa | 256 | - |
| Stati del flusso di lavoro definiti per un tipo di elemento di lavoro | 32 | 16 |
| Regole definite per un tipo di elemento di lavoro | 1024 | 1024 |
| Azioni definite per un tipo di elemento di lavoro | 1024 | 1024 |
| Azioni definite per una regola | 10 | 10 |
| Livelli di backlog portfolio definiti per un processo | 5 | 5 |
| Categorie definite per un processo | - | 32 |
| Elenchi globali definiti per un processo | - | 256 |
| Elementi di elenco definiti all'interno di un elenco globale | - | 1024 |
| Dimensioni degli allegati degli elementi di lavoro | 60 MB | 60 MB |
Per altre restrizioni e requisiti di conformità del modello di processo XML ospitato, vedere Personalizzare un processo quando si usa Hosted XML.
Nota
Per il modello di processo XML ospitato, è possibile definire circa 10.000 elementi in tutti gli elenchi globali specificati in tutte le reti wit.
La tabella seguente elenca il numero massimo di oggetti che è possibile definire per i modelli di processo XML locali e ereditarietà. Anche se questi limiti sono limiti rigidi, potrebbero essere applicati anche limiti pratici.
| Object | Ereditarietà | XML locale |
|---|---|---|
| Numero di processi che è possibile avere in un'organizzazione | 64 | 64 |
| Tipi di elementi di lavoro definiti per un processo | 64 | 64 |
| Campi definiti per una raccolta | 8192 | 1024 |
| Campi definiti per un processo | 1024 | 1024 |
| Campi definiti per un tipo di elemento di lavoro | 1024 | 1024 |
| Elenchi di selezione definiti per una raccolta | 1024 | N/D |
| Elementi elenco di selezione definiti per un elenco | 2048 | 2048 |
| Lunghezza carattere elemento elenco a discesa | 256 | N/D |
| Stati del flusso di lavoro definiti per un tipo di elemento di lavoro | 32 | 16 |
| Regole definite per un tipo di elemento di lavoro | 1024 | 1024 |
| Livelli di backlog portfolio definiti per un processo | 5 | 5 |
| Categorie definite per un processo | N/D | 32 |
| Elenchi globali definiti per un processo | N/D | 256 |
| Elementi di elenco definiti all'interno di un elenco globale | N/D | 1024 |
Nota
Per il modello di processo XML locale, è possibile definire un totale approssimativo di 10.000 elementi per tutti gli elenchi globali specificati in tutte le connessioni WIT.
Limiti pratici
Per ridurre al minimo i problemi di prestazioni, è consigliabile seguire queste indicazioni:
- Limitare il numero di campi personalizzati definiti. Tutti i campi personalizzati contribuiscono al totale consentito per un processo, una raccolta o un'organizzazione. È possibile specificare comportamenti diversi, ad esempio regole ed elenchi a discesa, per lo stesso campo in wit diversi.
- Limitare il numero di regole definite per un WIT. Anche se è possibile creare più regole per un WIT, altre regole possono influire negativamente sulle prestazioni quando gli utenti aggiungono o modificano elementi di lavoro. Quando gli utenti salvano gli elementi di lavoro, il sistema convalida tutte le regole associate ai campi per il tipo di elemento di lavoro. In alcuni casi, l'espressione di convalida delle regole potrebbe essere troppo complessa per la valutazione efficiente di SQL.
- Limitare il numero di wit personalizzati definiti.
- Limitare il numero di campi personalizzati definiti. Tutti i campi personalizzati contribuiscono al totale consentito per un processo, una raccolta o un'organizzazione. È possibile specificare comportamenti diversi, ad esempio regole ed elenchi a discesa, per lo stesso campo in wit diversi.
- Limitare il numero di regole definite per un WIT. Anche se è possibile creare più regole per un WIT, altre regole possono influire negativamente sulle prestazioni quando gli utenti aggiungono o modificano elementi di lavoro. Quando gli utenti salvano gli elementi di lavoro, il sistema convalida tutte le regole associate ai campi per il tipo di elemento di lavoro. In alcuni casi, l'espressione di convalida delle regole potrebbe essere troppo complessa per la valutazione efficiente di SQL.
- Limitare il numero di wit personalizzati definiti.
- Limitare il numero di campi segnalabili definiti. I campi reportabili possono influire sulle prestazioni del data warehouse.
Nota
La convalida delle regole degli elementi di lavoro supera i limiti SQL: una singola espressione SQL viene definita per ogni progetto per convalidare gli elementi di lavoro ogni volta che vengono creati o aggiornati. Questa espressione aumenta con il numero di regole specificate per tutti i tipi di elemento di lavoro nel progetto. Ogni qualificatore comportamentale per un campo aumenta il numero di espressioni secondarie. Regole annidate, regole che si applicano solo a una transizione o regole condizionali sul valore di un altro campo aggiungono altre condizioni a un'istruzione IF. Quando l'espressione raggiunge una determinata dimensione o complessità, SQL non può più valutarlo e genera un errore. Per risolvere questo errore, rimuovere alcune connessioni WIT o eliminare alcune regole.
Limiti di richieste inviate al bot
Per ridurre i costi e migliorare la scalabilità e le prestazioni, Azure DevOps Services, come molte soluzioni Software-as-a-Service, usa la multi-tenancy. Per garantire prestazioni ottimali e ridurre al minimo il rischio di interruzioni, Azure DevOps Services limita le risorse che gli utenti possono usare e il numero di richieste che possono effettuare a determinati comandi. Quando questi limiti vengono superati, le richieste successive potrebbero essere ritardate o bloccate.
La maggior parte dei limiti di velocità viene raggiunta tramite chiamate API REST o query non ottimizzate. Per altre informazioni, vedere Limiti di frequenza e procedure consigliate per evitare di raggiungere i limiti di frequenza.
Eseguire la migrazione e l'importazione dei limiti
Quando si esegue la migrazione dall'ambiente locale ad Azure DevOps Services, è possibile che si verifichino diversi limiti di dimensioni, tra cui:
- Dimensioni del database che superano le dimensioni consigliate
- Dimensioni massime della tabella che superano le dimensioni consigliate
- Dimensioni dei metadati del database che superano le dimensioni supportate
Per altre informazioni, vedere Eseguire la migrazione dei dati da Azure DevOps Server ad Azure DevOps Services e Risolvere gli errori di importazione e migrazione.