Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Cet article décrit les limites opérationnelles et d’objets qu’Azure DevOps place sur les opérations de suivi du travail et les personnalisations. Certaines limites pratiques s’appliquent également. Tenez compte de ces limites lorsque vous personnalisez les types d’éléments de travail (WIT).
Éléments de travail et requêtes
Les limites suivantes s’appliquent aux définitions d’élément de travail et de requête.
| Object | Limite |
|---|---|
| Pièces jointes par élément de travail | 100 |
| Taille de pièce jointe | 60 Mo |
| Champ de texte long | 1M 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 par dossier | 999 requêtes |
| Liens d’élément de travail par élément de travail | 1 000 |
| Balises d’élément de travail par é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 ne s’applique pas aux mises à jour à partir du portail web.
| Object | Limite |
|---|---|
| Champ de texte long | 1M caractères |
| Balises d’élément de travail par élément de travail | 100 |
| Liens d’élément de travail par élément de travail | 1 000 |
| Pièces jointes par é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 par 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 plus d’informations sur l’amélioration des performances des requêtes, consultez les meilleures pratiques pour définir une requête.
Backlogs, tableaux de bord et équipes
Les limites opérationnelles et d’objets suivantes s’appliquent aux équipes, aux étiquettes d’éléments de travail, aux backlogs et aux tableaux.
| Composant | Limite |
|---|---|
| Retards de traitement | 10 000 éléments de travail affichés* |
| Boards | 1 000 cartes à l’exclusion des cartes dans les catégories d’étatProposé et Terminé |
| Tableau de tâches | 1 000 tâches |
| Chemins de zone par projet | 10 000 |
| Chemins de zone par équipe | 300 |
| Profondeur du chemin d’accès à la zone | 14 niveaux |
| Chemins d’itération par projet | 10 000 |
| Chemins d’itération par équipe | 300 |
| Profondeur du chemin d’itération | 14 niveaux |
| Tableaux de bord de projet par projet | 500, accessible au niveau du projet à toute personne disposant d’un accès au projet |
| Tableaux de bord d’équipe par équipe | 500, spécifiques à l’équipe et utilisées pour suivre les métriques et données spécifiques à l’équipe |
| Teams par projet | 5 000 |
| Balises d’élément de travail par élément de travail | 100 |
| Balises d’élément de travail par organisation ou collection | 150 000 |
| Plans de livraison par projet | 1,500 |
| Modèles par type d’élément de travail | 100 |
*Chaque backlog peut afficher jusqu’à 10 000 éléments de travail, mais il n’existe aucune limite spécifique quant au nombre d’éléments de travail que vous pouvez définir. Si votre backlog dépasse 10 000 éléments, 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 du tableau de bord, vous pouvez effectuer les actions suivantes pour réduire leur nombre.
- Passez en revue la dernière date ou vérifiez auprès des membres de l’équipe, puis supprimez les tableaux de bord qui sont des doublons ou inutilisés.
- Exportez les données, puis archivez les anciens tableaux de bord.
- Combinez et consolidez des tableaux de bord similaires en ajoutant d’autres widgets aux tableaux de bord.
- Utilisez le suivi de limite d’objets pour 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. Pour plus d’informations, consultez Présentation du suivi des limites d’objets dans Azure DevOps.
Autres limites
- Les éléments de travail terminés ou fermés ne s’affichent pas sur les backlogs et les tableaux si 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 que les éléments apparaissent 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 carte multiteam.
- Par défaut, les limites des éléments de travail peuvent être définies sur des valeurs inférieures initialement.
Les limites d’affichage et d’objet opérationnelles suivantes s’appliquent aux équipes, aux étiquettes d’éléments de travail, aux backlogs et aux tableaux.
| Composant | Limite |
|---|---|
| Arriérés* | 999 éléments de travail |
| Boards | 400 cartes |
| Tableaux de bord par projet | 500 |
| Tableau de tâches | 800 éléments de travail |
| Teams par projet | 5 000 |
| Balises d’élément de travail par projet | 150 000 |
| Balises d’élément de travail par élément de travail | 100 |
| 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 limites
- É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 carte multiteam.
- Pour le modèle de processus XML local, vous pouvez modifier les limites du backlog et de la carte en modifiant le fichier ProcessConfiguration.xml . Pour plus d’informations, consultez la référence des éléments XML de configuration de processus.
Intégration de GitHub
Si vous intégrez votre projet à GitHub, les limites suivantes s’appliquent.
| Intégration | Limite |
|---|---|
| Interface utilisateur web Azure Boards | 1 000 dépôts GitHub connectés par connexion |
| API Azure Boards* | 2 000 dépôts GitHub connectés par connexion |
*Pour plus d’informations, consultez Connexions GitHub - Obtenir des connexions GitHub.
Projets
Azure DevOps Services limite chaque organisation à 1 000 projets, une augmentation par rapport à la limite précédente de 300 projets. 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 sur les projets par collection, mais les problèmes de performances peuvent survenir au fur et à mesure que le nombre de projets proches de 300. Certaines expériences, telles que la connexion à un projet à partir de Visual Studio, peuvent se dégrader.
Lors de la migration vers Azure DevOps Services, observez une 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
Il existe de nombreuses limites sur le 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é. Les limites pratiques peuvent également s’appliquer.
| Object | Héritage | XML hébergé |
|---|---|---|
| Nombre de processus par organisation | 128 | 64 |
| Types d’éléments de travail par processus | 64 | 64 |
| Champs par organisation | 8192 | 8192 |
| Champs par processus | 1 024 | 1 024 |
| Champs par type d’élément de travail | 1 024 | 1 024 |
| Listes de sélections par organisation | 2 048 | - |
| Éléments de liste de sélection par liste | 2 048 | 2 048 |
| Longueur du caractère de l’élément de liste de sélection | 256 | - |
| États de flux de travail par type d’élément de travail | 32 | 16 |
| Pages (onglets) par type d’élément de travail | 16 | 16 |
| Groupes par page | 32 | 32 |
| Règles par type d’élément de travail | 1 024 | 1 024 |
| Actions par type d’élément de travail | 1 024 | 1 024 |
| Actions par règle | 10 | 10 |
| Niveaux de backlog de portefeuille par processus | 5 | 5 |
| Catégories par processus | - | 32 |
| Taille de pièce jointe de l’élément de travail | 60 Mo | 60 Mo |
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. 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é.
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. Les limites pratiques peuvent également s’appliquer.
| Object | Héritage | XML local |
|---|---|---|
| Nombre de processus par collection | 64 | 64 |
| Types d’éléments de travail par processus | 64 | 64 |
| Champs par collection | 8192 | 1 024 |
| Champs par processus | 1 024 | 1 024 |
| Champs par type d’élément de travail | 1 024 | 1 024 |
| Listes de sélections par collection | 1 024 | N/A |
| Éléments de liste de sélection par liste | 2 048 | 2 048 |
| Longueur du caractère de l’élément de liste de sélection | 256 | N/A |
| États de flux de travail par type d’élément de travail | 32 | 16 |
| Règles par type d’élément de travail | 1 024 | 1 024 |
| Niveaux de backlog de portefeuille par processus | 5 | 5 |
| Catégories par processus | N/A | 32 |
| Listes globales par processus | N/A | 256 |
| Éléments de liste par 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, suivez ces instructions :
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.
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.
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 IF instruction.
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. Une fois que l’expression atteint une certaine taille ou complexité, SQL ne peut plus l’évaluer efficacement et peut générer une erreur. Pour résoudre cette erreur, supprimez certains WIT ou supprimez certaines règles.
Limites du taux de transfert
Azure DevOps Services, comme de nombreuses solutions Software-as-a-Service, utilise l’architecture mutualisée pour réduire les coûts et améliorer la scalabilité et les performances. 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.
Limites de migration et d’importation
Lorsque vous migrez à partir d’Azure DevOps Server local vers Azure DevOps Services, vous pouvez rencontrer les problèmes de taille suivants :
- 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.