Limites du suivi du travail, des processus et des projets

  • Article

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

Cet article définit les limites opérationnelles et d’objets placées sur les opérations de suivi du travail et la personnalisation du suivi du travail. Outre les limites matérielles spécifiées sur les objets sélectionnés, certaines limites pratiques s’appliquent. Lorsque vous personnalisez les types d’éléments de travail (WIT), tenez compte des limites placées sur les objets.

Éléments de travail et requêtes

Lors de la définition d’éléments de travail ou d’exécution de requêtes, les limites opérationnelles suivantes s’appliquent.

Object Limite
Pièces jointes ajoutées à un élément de travail 100
Taille de pièce jointe 60 Mo
Champ de texte long 1 M caractères
Durée d’exécution de la requête 30 secondes
Résultats de la requête 20 000 éléments
Longueur de la requête 32 000 caractères
Requêtes partagées sous un dossier 999 requêtes
Liens d’élément de travail attribués à un élément de travail 1 000
Balises d’élément de travail affectées à un élément de travail 100
Révisions d’éléments de travail (API REST) 10 000
Requêtes favorites par projet 200 requêtes

Une limite de révision des éléments de travail de 10 000 est en vigueur pour les mises à jour effectuées via l’API REST pour Azure DevOps Services. Cette limite restreint les mises à jour de l’API REST. Toutefois, les mises à jour du portail web ne sont pas affectées.

Object Limite
Champ de texte long 1 M caractères
Balises d’élément de travail affectées à un élément de travail 100
Liens d’élément de travail attribués à un élément de travail 1 000
Pièces jointes ajoutées à un élément de travail 100
Taille de pièce jointe 4 Mo à 2 Go
Durée d’exécution de la requête 6 minutes
Résultats de la requête 20 000 éléments
Longueur de la requête 32 000 caractères
Requêtes partagées sous un dossier 999 requêtes
Requêtes favorites par projet 200 requêtes

La taille de pièce jointe maximale par défaut est de 4 Mo. Vous pouvez modifier la taille maximale jusqu’à 2 Go.

Pour améliorer les performances des requêtes, consultez Définir une requête/meilleures pratiques.

Backlogs, tableaux de bord et équipes

Lorsque vous travaillez avec des équipes, des étiquettes d’éléments de travail, des backlogs et des tableaux, les limites d’affichage et d’objet opérationnelles suivantes s’appliquent.

Interface utilisateur Limite
Retards de traitement 10 000 éléments de travail
Boards 1 000 carte (à l’exception de ces carte dans les catégories d’état de flux de travail proposés et terminés)
Tableau de tâches 1 000 tâches
Chemins de zone 10 000 par projet
Profondeur du chemin d’accès à la zone 14
Chemins d’accès de zone par équipe 300
Chemins d’itération 10 000 par projet
Profondeur du chemin d’itération 14
Chemins d’itération par équipe 300
Tableaux de bord de projet 500 par projet
Tableaux de bord d’équipe 500 par équipe
Teams 5 000 par projet
Étiquettes d’élément de travail 150 000 définitions d’étiquettes par organisation ou collection
Plans de livraison par projet 1 000
Modèles par type d’élément de travail 100

Chaque backlog peut afficher jusqu’à 10 000 éléments de travail. Il s’agit d’une limite sur ce que le backlog peut afficher, et non sur le nombre d’éléments de travail que vous pouvez définir. Si votre backlog dépasse cette limite, vous pouvez envisager d’ajouter une équipe et de déplacer certains éléments de travail vers le backlog de l’autre équipe.

Notes supplémentaires :

  • Les éléments de travail terminés ou fermés ne s’affichent pas sur les backlogs et les tableaux une fois que leur Date de modification remonte à plus d’un an. Vous pouvez toujours répertorier ces éléments à l’aide d’une requête. Si vous souhaitez qu’ils apparaissent sur un backlog ou une carte, vous pouvez apporter une modification mineure à celles-ci qui réinitialisent l’horloge pour l’affichage.
  • Évitez d’imbriquer les éléments de backlog du même type. Pour plus d’informations, consultez Corriger les problèmes de réorganisation et d’imbrication.
  • Évitez d’affecter les mêmes chemins de zone à plusieurs équipes. Pour plus d’informations, consultez Limitations des vues de tableau Kanban multi-équipe.
  • Par défaut, les limites des éléments de travail peuvent être initialement configurées pour réduire les valeurs.

Lorsque vous travaillez avec des équipes, des étiquettes d’éléments de travail, des backlogs et des tableaux, les limites opérationnelles suivantes s’appliquent. Limites par défaut et maximales.

Interface utilisateur Limite
Retards de traitement 999 éléments de travail
Boards 400 carte s
Tableaux de bord par projet 500
Tableau de tâches 800 éléments de travail
Teams 5 000 par projet
Étiquettes d’élément de travail 150 000 définitions d’étiquettes par projet
Modèles par type d’élément de travail 100

Chaque backlog peut afficher jusqu’à 999 éléments de travail. Si votre backlog dépasse cette limite, vous pouvez envisager d’ajouter une équipe et de déplacer certains éléments de travail vers le backlog de l’autre équipe.

Notes supplémentaires :

  • Évitez d’imbriquer les éléments de backlog du même type. Pour plus d’informations, consultez Corriger les problèmes de réorganisation et d’imbrication.
  • Évitez d’affecter les mêmes chemins de zone à plusieurs équipes. Pour plus d’informations, consultez Limitations des vues de tableau Kanban multi-équipe.

Pour le modèle de processus XML local, vous pouvez modifier les limites du backlog et du tableau des tâches en modifiant le fichier ProcessConfiguration.xml. Pour plus d’informations, consultez la référence des éléments XML de configuration de processus.

Projets

Azure DevOps Services limite chaque organisation à 1 000 projets par organisation, une augmentation par rapport à la limite précédente de 300 projets.

Remarque

Au-dessus de 300 projets, certaines expériences, telles que la connexion à un projet à partir de Visual Studio, peuvent commencer à se dégrader. Pour azure DevOps Server local, il n’existe aucune limite stricte au nombre de projets. Toutefois, vous pouvez rencontrer des problèmes de performances si le nombre de projets approche 300. Si vous envisagez de migrer votre collection locale vers Azure DevOps Services, vous devez observer la limite maximale de 1 000 projets. Si votre collection comporte plus de 1 000 projets, vous devez fractionner la collection ou supprimer des projets plus anciens.

Pour plus d'informations, consultez Migrer les données d'Azure DevOps Server vers Azure DevOps Services.

Personnalisation du processus

Un certain nombre de limites sont imposées au nombre d’objets que vous pouvez définir pour un processus. Pour en savoir plus sur les modèles de processus, consultez Personnaliser votre expérience de suivi de travail.

Le tableau suivant répertorie le nombre maximal d’objets que vous pouvez définir pour les modèles de processus Héritage et XML hébergé. Bien que ces limites représentent des limites difficiles, les limites pratiques peuvent également s’appliquer.

Object Héritage XML hébergé
Nombre de processus que vous pouvez avoir dans une organisation 128 64
Les types d’élément de travail définis pour un processus 64 64
Champs définis pour une organisation 8 192 8 192
Champs définis pour un processus 1 024 1 024
Champs définis pour un type d’élément de travail 1 024 1 024
Listes de sélection définies pour une organisation ou une collection 2 048 -
Éléments de liste de sélection définis pour une liste 2 048 2 048
Longueur du caractère de l’élément de liste de sélection 256 -
Les états du workflow définis pour un type d’élément de travail 32 16
Les règles définies pour un type d’élément de travail 1 024 1 024
Actions définies pour une règle 10 10
Niveaux de backlog de portefeuille définis pour un processus 5 5
Catégories définies pour un processus - 32
Listes globales définies pour un processus - 256
Éléments de liste définis dans une liste globale - 1 024
Taille de pièce jointe de l’élément de travail 60 Mo 60 Mo

Pour connaître les restrictions supplémentaires et les exigences de conformité du modèle de processus XML hébergé, consultez Personnaliser un processus lors de l’utilisation du code XML hébergé.

Remarque

Pour le modèle de processus XML hébergé, vous pouvez définir un total approximatif de 10 000 éléments pour toutes les listes globales spécifiées sur tous les WIT.

Le tableau suivant répertorie le nombre maximal d’objets que vous pouvez définir pour les modèles de processus XML locaux et d’héritage. Bien que ces limites représentent des limites difficiles, les limites pratiques peuvent également s’appliquer.

Object Héritage XML local
Nombre de processus que vous pouvez avoir dans une organisation 64 64
Les types d’élément de travail définis pour un processus 64 64
Champs définis pour une collection 8192 1 024
Champs définis pour un processus 1 024 1 024
Champs définis pour un type d’élément de travail 1 024 1 024
Listes de sélection définies pour une collection 1 024 S/O
Éléments de liste de sélection définis pour une liste 2 048 2 048
Longueur du caractère de l’élément de liste de sélection 256 S/O
Les états du workflow définis pour un type d’élément de travail 32 16
Les règles définies pour un type d’élément de travail 1 024 1 024
Niveaux de backlog de portefeuille définis pour un processus 5 5
Catégories définies pour un processus S/O 32
Listes globales définies pour un processus S/O 256
Éléments de liste définis dans une liste globale S/O 1 024

Remarque

Pour le modèle de processus XML local, vous pouvez définir un total approximatif de 10 000 éléments pour toutes les listes globales spécifiées sur toutes les wiT.

Limites pratiques

Nous vous recommandons de prendre en compte les conseils suivants pour réduire les problèmes de performances.

  • Réduisez le nombre de champs personnalisés que vous définissez. Tous les champs personnalisés contribuent au total autorisé pour un processus, un regroupement ou une organisation. Notez que vous pouvez spécifier un comportement différent pour le même champ dans un autre WIT. Autrement dit, vous pouvez spécifier différentes règles, listes de sélection, etc.
  • Réduisez le nombre de règles que vous définissez pour un WIT. Même si vous pouvez créer plusieurs règles pour un WIT, des règles supplémentaires peuvent avoir un impact négatif sur les performances lorsqu’un utilisateur ajoute et modifie des éléments de travail. Lorsque les utilisateurs enregistrent des éléments de travail, le système valide toutes les règles associées aux champs pour son type d’élément de travail. Sous certaines conditions, l’expression de validation de la règle est trop complexe pour l’évaluation de SQL.
  • Réduisez le nombre de WIT personnalisés que vous définissez.
  • Réduisez le nombre de champs personnalisés que vous définissez. Tous les champs personnalisés contribuent au total autorisé pour un processus, un regroupement ou une organisation. Notez que vous pouvez spécifier un comportement différent pour le même champ dans un autre WIT. Autrement dit, vous pouvez spécifier différentes règles, listes de sélection, etc.
  • Réduisez le nombre de règles que vous définissez pour un WIT. Même si vous pouvez créer plusieurs règles pour un WIT, des règles supplémentaires peuvent avoir un impact négatif sur les performances lorsqu’un utilisateur ajoute et modifie des éléments de travail. Lorsque les utilisateurs enregistrent des éléments de travail, le système valide toutes les règles associées aux champs pour son type d’élément de travail. Sous certaines conditions, l’expression de validation de la règle est trop complexe pour l’évaluation de SQL.
  • Réduisez le nombre de WIT personnalisés que vous définissez.
  • Réduisez le nombre de champs reportables que vous définissez. Les champs reportables affectent les performances de votre entrepôt de données.

Remarque

La validation des règles d’élément de travail dépasse les limites SQL : une expression SQL unique est définie par projet pour valider les éléments de travail chaque fois qu’ils sont créés ou mis à jour. Cette expression augmente avec le nombre de règles que vous spécifiez pour tous les types d’éléments de travail définis pour le projet. Chaque qualificateur comportemental spécifié pour un champ entraîne une augmentation du nombre de sous-expressions. Les règles imbriquées, les règles qui s’appliquent uniquement à une transition ou conditionnées sur la valeur d’un autre champ, entraînent l’ajout de conditions supplémentaires à une instruction IF. Une fois que l’expression atteint une certaine taille ou complexité, SQL ne peut plus l’évaluer et génère une erreur. La suppression de certains WIT ou l’élimination de certaines règles peut résoudre l’erreur.

Limites du taux de transfert

Pour réduire les coûts et améliorer la scalabilité et les performances, Azure DevOps Services, comme de nombreuses solutions Software-as-a-Service, utilise plusieurs architectures. Pour garantir de bonnes performances et réduire la probabilité de pannes, Azure DevOps Services limite les ressources que les personnes peuvent consommer et le nombre de demandes qu’ils peuvent effectuer à certaines commandes. Lorsque ces limites sont dépassées, les demandes suivantes peuvent être retardées ou bloquées.

La plupart des limites de débit sont atteintes par le biais d’appels d’API REST ou de requêtes non optimisées. Pour en savoir plus, consultez les articles suivants :

Migrer et importer des limites

Lors de la détermination de la migration d’un site local vers Azure DevOps Services, il existe plusieurs limites de taille que vous pouvez rencontrer. Ces limites sont les suivantes :

  • La taille de la base de données est supérieure à la taille recommandée
  • La plus grande taille de table est supérieure à la taille recommandée
  • La taille des métadonnées de base de données est supérieure à la taille prise en charge

Pour plus d’informations, consultez Migrer des données d’Azure DevOps Server vers Azure DevOps Services et résoudre les erreurs d’importation et de migration.