Limites du suivi du travail, des processus et des projets
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 cartes (à l’exclusion de ces cartes dans les catégories d’état de flux de travail proposées et terminées) |
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 Résoudre 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 multi-équipes.
- 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 cartes |
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 Résoudre 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 multi-équipes.
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 | 8192 | 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 plus d’informations, 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.