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 gli oggetti selezionati, si applicano determinati 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, si applicano 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 |
Un limite di revisione dell'elemento di lavoro di 10.000 è attivo per gli aggiornamenti eseguiti tramite l'API REST per Azure DevOps Services. Questo limite limita gli aggiornamenti dall'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 i team, i tag degli elementi di lavoro, i backlog e le 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 |
Dashboard del team | 500 per 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. Si tratta di un limite per ciò che il backlog può visualizzare, non un limite al numero di elementi di lavoro che è possibile definire. Se il backlog supera questo limite, è consigliabile prendere in considerazione l'aggiunta di un team e lo spostamento di alcuni elementi di lavoro nel backlog dell'altro team.
Note aggiuntive:
- Gli elementi di lavoro completati o chiusi non vengono visualizzati nei backlog e nelle bacheche dopo che la data modificata è maggiore di un anno. È comunque possibile elencare questi elementi usando una query. Se si desidera che vengano visualizzati su un backlog o una lavagna, è possibile apportare una modifica secondaria a essi che reimposta l'orologio per la visualizzazione.
- 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 inizialmente configurati per ridurre i valori.
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, è consigliabile prendere in considerazione l'aggiunta di un team e lo spostamento di alcuni elementi di lavoro nel backlog dell'altro team.
Note aggiuntive:
- 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 file ProcessConfiguration.xml. Per informazioni dettagliate, vedere Informazioni di riferimento sull'elemento XML di configurazione del processo.
Progetti
Azure DevOps Services limita ogni organizzazione a 1000 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 iniziare a peggiorare. Per Azure DevOps Server locale, non esistono limiti rigidi al numero di progetti. Tuttavia, è possibile che si verifichino problemi di prestazioni se il numero di progetti si avvicina a 300. Se si prevede di eseguire la migrazione della raccolta locale ad Azure DevOps Services, è necessario osservare il limite massimo di 1000 progetti. Se la raccolta contiene più di 1000 progetti, sarà necessario 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
Un numero di limiti viene imposto al numero di oggetti che è possibile definire per un processo. Per informazioni sui modelli di processo, 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 rappresentano limiti rigidi, possono essere applicati 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 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 ulteriori 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 un totale approssimativo di 10.000 elementi per tutti gli elenchi globali specificati in tutte le connessioni 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 rappresentano limiti rigidi, possono essere applicati 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
È consigliabile prendere in considerazione le indicazioni seguenti per ridurre al minimo i problemi di prestazioni.
- Ridurre al minimo il numero di campi personalizzati definiti. Tutti i campi personalizzati contribuiscono al totale consentito per un processo, una raccolta o un'organizzazione. Si noti che è possibile specificare un comportamento diverso per lo stesso campo in un WIT diverso. In altre parole, è possibile specificare regole, elenchi a discesa e altro ancora.
- Ridurre al minimo il numero di regole definite per un WIT. Sebbene sia possibile creare più regole per un tipo di elemento di lavoro, l'aggiunta di regole può influire negativamente sulle prestazioni quando un utente aggiunge e modifica gli 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 determinate condizioni, l'espressione di convalida delle regole è troppo complessa essere valutata da SQL.
- Ridurre al minimo il numero di tipi di elementi di lavoro personalizzati definiti.
- Ridurre al minimo il numero di campi personalizzati definiti. Tutti i campi personalizzati contribuiscono al totale consentito per un processo, una raccolta o un'organizzazione. Si noti che è possibile specificare un comportamento diverso per lo stesso campo in un WIT diverso. In altre parole, è possibile specificare regole, elenchi a discesa e altro ancora.
- Ridurre al minimo il numero di regole definite per un WIT. Sebbene sia possibile creare più regole per un tipo di elemento di lavoro, l'aggiunta di regole può influire negativamente sulle prestazioni quando un utente aggiunge e modifica gli 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 determinate condizioni, l'espressione di convalida delle regole è troppo complessa essere valutata da SQL.
- Ridurre al minimo il numero di tipi di elementi di lavoro personalizzati definiti.
- Ridurre al minimo il numero di campi segnalabili definiti. I campi segnalabili influisce 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 definiti per il progetto. Ogni qualificatore comportamentale specificato per un campo comporta un aumento del numero di sottoespressione. Regole annidate, regole che si applicano solo a una transizione o condizionale sul valore di un altro campo, determinano l'aggiunta di più condizioni a un'istruzione IF. Quando l'espressione raggiunge una determinata dimensione o complessità, SQL non può valutarlo più e genera un errore. La rimozione di alcune connessioni WIT o l'eliminazione di alcune regole può risolvere l'errore.
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 multi-tenancy. Per garantire prestazioni ottimali e ridurre la probabilità 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 possono essere ritardate o bloccate.
La maggior parte dei limiti di frequenza viene raggiunta tramite chiamate API REST o query non ottimizzate. Per altre informazioni, vedere gli articoli seguenti:
Eseguire la migrazione e l'importazione dei limiti
Quando si determina la migrazione dall'ambiente locale ad Azure DevOps Services, possono verificarsi diversi limiti di dimensioni. Questi limiti includono:
- Le dimensioni del database superano le dimensioni consigliate
- Le dimensioni massime della tabella superano le dimensioni consigliate
- Le dimensioni dei metadati del database sono superiori alle 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.