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 des objets spécifiques, 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
Lorsque vous définissez des éléments de travail ou des requêtes en cours d’exécution, gardez à l’esprit les limites opérationnelles suivantes :
| Object | Limite |
|---|---|
| Pièces jointes ajoutées à un élément de travail | 100 |
| Taille de pièce jointe | 60 Mo |
| Champ de texte long | Caractères 1-M |
| 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 |
L’API REST pour Azure DevOps Services applique une limite de révision d’élément de travail de 10 000 mises à jour. Cette limite limite limite les mises à jour effectuées via l’API REST, mais les mises à jour du portail web ne sont pas affectées.
| Object | Limite |
|---|---|
| Champ de texte long | Caractères 1-M |
| 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.
Chaque backlog peut afficher jusqu’à 10 000 éléments de travail. Cette limite s’applique à ce que le backlog peut afficher, et non au nombre d’éléments de travail que vous pouvez définir, car il n’existe aucune limite spécifique. Si votre backlog dépasse cette limite, envisagez d’ajouter une équipe et de déplacer certains éléments de travail vers le backlog de la nouvelle équipe.
Conseil
Si vous approchez des limites des tableaux de bord, consultez les étapes suivantes pour gérer et nettoyer vos tableaux de bord :
- Révision de l’utilisation : identifiez les tableaux de bord qui ne sont plus utilisés ou sont des doublons. Pour ce faire, vérifiez la date du dernier accès ou en consultant les membres de l’équipe.
- Consolider les tableaux de bord : combinez des tableaux de bord similaires pour réduire le nombre total. Pour ce faire, ajoutez plusieurs widgets à un seul tableau de bord.
- Archivez les anciens tableaux de bord : si certains tableaux de bord ne sont plus nécessaires, mais que vous souhaitez conserver les données, envisagez d’exporter les données et d’archiver les tableaux de bord.
- Utilisez la fonctionnalité Object Limit Tracker : fournit une visibilité en temps réel sur l’utilisation des ressources, y compris les tableaux de bord. Cette fonctionnalité peut vous aider à gérer de manière proactive vos limites et à éviter les problèmes potentiels.
Autres remarques :
- 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 est antérieure à une année. Vous pouvez toujours répertorier ces éléments à l’aide d’une requête. Pour les rendre visibles sur un backlog ou une carte, apportez une modification mineure pour réinitialiser l’horloge d’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 définies sur des valeurs inférieures initialement.
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, envisagez de créer une équipe et de déplacer certains des éléments de travail vers le backlog de la nouvelle équipe.
Autres remarques :
- É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 d’accès 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 le backlog et les limites du Tableau des tâches en modifiant le ProcessConfiguration.xml fichier. 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, soit une augmentation de 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 se dégrader. Pour azure DevOps Server local, il n’existe aucune limite stricte, mais les problèmes de performances peuvent survenir au fur et à mesure que le nombre de projets proches de 300. Lors de la migration vers Azure DevOps Services, observez la limite maximale de 1 000 projets. Si votre collection dépasse cette limite, fractionnez la collection ou supprimez les projets plus anciens.
Pour plus d'informations, consultez Migrer les données d'Azure DevOps Server vers Azure DevOps Services.
Personnalisation du processus
De nombreuses limites sont imposées au nombre d’objets que vous pouvez définir pour un processus. Pour plus d’informations, consultez Personnaliser votre expérience de suivi du 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 soient des limites strictes, 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 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 d’autres restrictions et 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 environ 10 000 éléments dans toutes les listes globales spécifiées dans toutes les wiT.
Le tableau suivant répertorie le nombre maximal d’objets que vous pouvez définir pour les modèles de processus XML d’héritage et locaux. Bien que ces limites soient des limites strictes, 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 | N/A |
| É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 | N/A |
| 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 | N/A | 32 |
| Listes globales définies pour un processus | N/A | 256 |
| Éléments de liste définis dans une liste globale | N/A | 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
Pour réduire les problèmes de performances, nous vous recommandons de suivre ces conseils :
- Limitez 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. Vous pouvez spécifier différents comportements, tels que les règles et les listes de sélection, pour le même champ dans différents WITs.
- Limitez le nombre de règles que vous définissez pour un WIT. Bien que vous puissiez créer plusieurs règles pour un WIT, d’autres règles peuvent affecter négativement les performances lorsque les utilisateurs ajoutent ou modifient 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 de ce type d’élément de travail. Dans certains cas, l’expression de validation de règle peut être trop complexe pour que SQL évalue efficacement.
- Limitez le nombre de WIT personnalisés que vous définissez.
- Limitez 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. Vous pouvez spécifier différents comportements, tels que les règles et les listes de sélection, pour le même champ dans différents WITs.
- Limitez le nombre de règles que vous définissez pour un WIT. Bien que vous puissiez créer plusieurs règles pour un WIT, d’autres règles peuvent affecter négativement les performances lorsque les utilisateurs ajoutent ou modifient 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 de ce type d’élément de travail. Dans certains cas, l’expression de validation de règle peut être trop complexe pour que SQL évalue efficacement.
- Limitez le nombre de WIT personnalisés que vous définissez.
- Limitez le nombre de champs reportables que vous définissez. Les champs reportables peuvent affecter 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 spécifiées pour tous les types d’éléments de travail dans le projet. Chaque qualificateur comportemental pour un champ augmente le nombre de sous-expressions. Les règles imbriquées, les règles qui s’appliquent uniquement à une transition ou les règles conditionnées à la valeur d’un autre champ ajoutent d’autres conditions à 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. Pour résoudre cette erreur, supprimez certains WIT ou supprimez certaines règles.
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 une architecture mutualisée. Pour garantir de bonnes performances et réduire le risque 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 requêtes 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 limites de débit et les meilleures pratiques (pour éviter d’atteindre les limites de taux).
Migrer et importer des limites
Lors de la migration d’un site local vers Azure DevOps Services, vous pouvez rencontrer plusieurs limites de taille, notamment :
- Taille de base de données supérieure à la taille recommandée
- Taille de table supérieure à la taille recommandée
- Taille des métadonnées de base de données 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.