Limiti di progetti, processi e rilevamento del lavoro

  • Articolo

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 di 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 Kanban multi-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 Kanban multi-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 ulteriori 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.