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 qui Azure DevOps placent 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).
Conseil
Utilisez le suivi de limite d’objets pour une visibilité en temps réel de l’utilisation des ressources de votre organisation dans toutes les catégories de limites. Pour plus d’informations, consultez Présentation du suivi des limites d’objets dans Azure DevOps.
É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 s’applique uniquement aux mises à jour de l’API REST et n’affecte pas les mises à jour effectuées via le portail web. Si vous automatisez les mises à jour d’éléments de travail via l’API et que vous rencontrez cette limite, envisagez de créer un élément de travail pour continuer le suivi au lieu de mettre à jour l’élément existant.
Que se passe-t-il lorsque vous atteignez une limite :
- Durée d’exécution de la requête : La requête s’arrête et retourne une erreur de délai d’expiration. Ajoutez des conditions de filtre ou des plages de dates plus spécifiques pour réduire l’étendue.
- Résultats de la requête : Les résultats sont tronqués à 20 000 éléments : aucune erreur n’est affichée. Affinez vos conditions de filtre ou fractionnez la requête en plusieurs requêtes enregistrées.
- Taille de pièce jointe : La pièce jointe est rejetée au moment du chargement avec un message d’erreur. Compressez ou fractionnez le fichier avant d’attacher.
- Liens d’élément de travail : Les nouveaux liens sont bloqués lorsque la limite est atteinte. Envisagez de consolider des liens connexes ou d’archiver des éléments de travail plus anciens.
| 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.
Si une requête expire ou retourne trop de résultats, consultez les meilleures pratiques pour définir une requête pour obtenir des conseils sur l’optimisation des performances des requêtes.
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 |
| Project tableaux de bord par project | 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.
Que se passe-t-il lorsque vous atteignez une limite :
- Affichage du backlog : Les éléments de travail au-delà de la limite d’affichage sont masqués dans le backlog, mais ne sont pas supprimés. Utilisez une requête pour rechercher et gérer les éléments masqués.
- Cartes de carte : Les cartes au-delà de la limite sont masquées à partir de la vue du tableau. Les éléments des catégories d’état Proposé et Terminé ne comptent pas vers la limite de 1 000 cartes.
- Limite du tableau de bord : Les nouveaux tableaux de bord ne peuvent pas être créés une fois la limite atteinte. Passez en revue et supprimez les tableaux de bord inutilisés pour libérer de l’espace.
Conseil
Si vous approchez des limites du tableau de bord, effectuez les actions suivantes pour réduire leur nombre.
- Passez en revue la dernière date ou vérifiez avec les 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.
Considérations supplémentaires
- Les backlogs et les tableaux n’affichent pas d’éléments de travail terminés ou fermés si leur date de modification est antérieure à un an. Ce comportement est attendu, pas un bogue. Vous pouvez toujours trouver ces éléments de travail en exécutant une requête. Pour faire réapparaître un élément de travail sur un backlog ou une carte, effectuez une mise à jour mineure pour réinitialiser sa date modifiée , par exemple, ajouter un commentaire ou mettre à jour une valeur de champ.
- É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.
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 |
| Étiquettes d’élément de travail par organisation ou collection de projets | 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.
Considérations 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 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 integratiez votre projet avec GitHub, les limites suivantes s’appliquent.
| Intégration | Limite |
|---|---|
| interface utilisateur web Azure Boards | 1 000 référentiels de GitHub connectés par connexion |
| API Azure Boards* | 2 000 référentiels de GitHub connectés par connexion |
*Pour plus d’informations, consultez GitHub Connexions - Obtenir des connexions GitHub.
Que se passe-t-il lorsque vous atteignez une limite : Lorsqu’une connexion atteint sa limite de référentiel, vous ne pouvez pas ajouter d’autres référentiels à cette connexion. Créez une connexion GitHub pour ajouter des référentiels supplémentaires.
Projets
Azure DevOps Services limite chaque organisation à 1 000 projets. Lorsque vous dépassez 300 projets, certaines expériences, telles que la connexion à un projet à partir de Visual Studio, peuvent se dégrader. Si vous rencontrez des problèmes de performances dans une organisation avec de nombreux projets, envisagez de consolider des projets ou de distribuer le travail entre plusieurs organisations.
Pour les Azure DevOps Server locales, 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 Migrate des données de Azure DevOps Server vers Azure DevOps Services.
Personnalisation du processus
Les limites existent 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 | 256 | 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
Même lorsque vous êtes dans les limites des objets durs, les performances peuvent se dégrader à mesure que le nombre d’objets personnalisés augmente. Les instructions suivantes représentent la plage d’exploitation recommandée Microsoft pour des performances prévisibles. 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.
Conseil
Si les utilisateurs voient des erreurs lors de l’enregistrement d’éléments de travail et que vous avez fortement personnalisé des règles, passez en revue le nombre de règles dans tous les WIT du projet. La réduction des règles conditionnelles (telles que celles qui s’appliquent uniquement pendant les transitions d’état ou dépend de la valeur d’un autre champ) a le plus grand impact sur la réduction de la complexité des expressions.
Limites du taux de transfert
Azure DevOps Services, comme de nombreuses solutions de logiciels en tant que 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 les utilisateurs dépassent ces limites, le service peut retarder ou bloquer les demandes suivantes.
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 des Azure DevOps Server locales vers Azure DevOps Services, votre collection doit répondre aux exigences de taille suivantes :
| Mesure | Limite recommandée |
|---|---|
| Taille de base de données totale | 150 Go |
| Plus grande table individuelle | 30 Go |
| Taille des métadonnées de base de données | 2 Go |
Si votre collection dépasse ces limites, la validation de la migration échoue avant le transfert de données. Pour résoudre le problème, consultez Résoudre les erreurs d’importation et de migration pour les options, notamment le nettoyage des données et le fractionnement de collecte. Pour connaître le processus de migration complet, consultez Migrer des données de Azure DevOps Server vers Azure DevOps Services.