Compartir a través de


Seguimiento del trabajo, proceso y límites del proyecto

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

En este artículo se describen los límites operativos y de objetos que Azure DevOps coloca en las operaciones y personalizaciones de seguimiento del trabajo. También se aplican algunos límites prácticos. Tenga en cuenta estos límites al personalizar los tipos de elementos de trabajo (WIT).

Elementos de trabajo y consultas

Los límites siguientes se aplican a las definiciones de consulta y elemento de trabajo.

Object Límite
Datos adjuntos por elemento de trabajo 100
Tamaño de datos adjuntos 60 MB
Campo de texto largo 1M caracteres
Tiempo de ejecución de consulta 30 segundos
Resultados de la consulta 20 000 elementos
Longitud de la consulta 32 000 caracteres
Consultas compartidas por carpeta 999 consultas
Vínculos de elementos de trabajo por elemento de trabajo 1,000
Etiquetas de elemento de trabajo por elemento de trabajo 100
Revisiones de elementos de trabajo (API REST)* 10,000
Consultas favoritas por proyecto 200 consultas

*La API REST para Azure DevOps Services aplica un límite de revisión de elementos de trabajo de 10 000 actualizaciones. Este límite restringe las actualizaciones realizadas a través de la API REST, pero no se aplica a las actualizaciones desde el portal web.

Object Límite
Campo de texto largo 1M caracteres
Etiquetas de elemento de trabajo por elemento de trabajo 100
Vínculos de elementos de trabajo por elemento de trabajo 1,000
Datos adjuntos por elemento de trabajo 100
Tamaño de datos adjuntos* 4 MB a 2 GB
Tiempo de ejecución de consulta 6 minutos
Resultados de la consulta 20 000 elementos
Longitud de la consulta 32 000 caracteres
Consultas compartidas por carpeta 999 consultas
Consultas favoritas por proyecto 200 consultas

*El tamaño máximo de datos adjuntos predeterminado es de 4 MB. Puede cambiar el tamaño máximo de hasta 2 GB.

Para obtener información sobre cómo mejorar el rendimiento de las consultas, consulte Procedimientos recomendados para definir una consulta.

Trabajos pendientes, paneles, paneles y equipos

Los siguientes límites operativos y de objetos se aplican a equipos, etiquetas de elementos de trabajo, trabajos pendientes y paneles.

Componente Límite
Trabajos pendientes 10 000 elementos de trabajo mostrados*
Boards 1000 tarjetas sin incluir tarjetas en las categorías de estadoPropuesta y Completada
Panel de tareas 1000 tareas
Rutas de acceso de área por proyecto 10,000
Rutas de acceso de área por equipo 300
Profundidad de la ruta de acceso del área 14 niveles
Rutas de acceso de iteración por proyecto 10,000
Rutas de acceso de iteración por equipo 300
Profundidad de la ruta de acceso de iteración 14 niveles
Paneles de proyecto por proyecto 500, accesible en el nivel de proyecto a cualquier persona con acceso al proyecto
Paneles de equipo por equipo 500, específico del equipo y usado para realizar un seguimiento de métricas y datos específicos del equipo
Teams por proyecto 5.000
Etiquetas de elemento de trabajo por elemento de trabajo 100
Etiquetas de elemento de trabajo por organización o colección 150,000
Planes de entrega por proyecto 1,500
Plantillas por tipo de elemento de trabajo 100

*Cada trabajo pendiente puede mostrar hasta 10 000 elementos de trabajo, pero no hay ningún límite específico en el número de elementos de trabajo que puede definir. Si el trabajo pendiente supera los 10 000 elementos, considere la posibilidad de agregar un equipo y mover algunos elementos de trabajo al trabajo pendiente del nuevo equipo.

Sugerencia

Si se aproxima a los límites del panel, puede realizar las siguientes acciones para reducir su número.

  • Revise la última fecha de acceso o compruebe con los miembros del equipo y, a continuación, quite los paneles duplicados o que no se usen.
  • Exporte los datos y, a continuación, archive los paneles antiguos.
  • Combine y consolide paneles similares agregando más widgets a los paneles.
  • Use el Rastreador de límites de objetos para obtener visibilidad en tiempo real del uso de recursos, incluidos los paneles. Esta característica puede ayudarle a administrar de forma proactiva los límites y a evitar posibles problemas. Para más información, consulte Introducción al rastreador de límites de objetos en Azure DevOps.

Otros límites

  • Los elementos de trabajo completados o cerrados no se muestran en trabajos pendientes y paneles si su fecha modificada es anterior a un año. Puede enumerar estos elementos mediante una consulta. Para que los elementos aparezcan en un trabajo pendiente o en un panel, realice un cambio menor para restablecer el reloj de presentación.
  • Evite anidar elementos de trabajo pendiente del mismo tipo. Para obtener más información, consulte Corrección de problemas de reordenación y anidamiento.
  • Evite asignar las mismas rutas de acceso de área a más de un equipo. Para obtener más información, consulte Limitaciones de las vistas de placa multiteam.
  • De forma predeterminada, los límites de elementos de trabajo pueden establecerse en valores inferiores inicialmente.

Los siguientes límites de objetos y visualización operativa se aplican a equipos, etiquetas de elementos de trabajo, trabajos pendientes y paneles.

Componente Límite
Trabajos pendientes* 999 elementos de trabajo
Boards 400 tarjetas
Paneles por proyecto 500
Panel de tareas 800 elementos de trabajo
Teams por proyecto 5.000
Etiquetas de elemento de trabajo por proyecto 150,000
Etiquetas de elemento de trabajo por elemento de trabajo 100
Plantillas por tipo de elemento de trabajo 100

*Cada trabajo pendiente puede mostrar hasta 999 elementos de trabajo. Si el trabajo pendiente supera este límite, considere la posibilidad de crear un nuevo equipo y mover algunos de los elementos de trabajo al trabajo pendiente del nuevo equipo.

Otros límites

Integración de GitHub

Si integras tu proyecto con GitHub, se aplican los siguientes límites.

Integración Límite
Interfaz de usuario web de Azure Boards 1000 repositorios de GitHub conectados por conexión
API de Azure Boards* 2000 repositorios de GitHub conectados por conexión

*Para obtener más información, consulte Conexiones de GitHub: obtener conexiones de GitHub.

Proyectos

Azure DevOps Services limita cada organización a 1000 proyectos, lo que aumenta el límite anterior de 300 proyectos. Más de 300 proyectos, determinadas experiencias, como la conexión a un proyecto desde Visual Studio, pueden degradarse.

En el caso de Azure DevOps Server local, no hay límites estrictos en los proyectos por colección, pero pueden surgir problemas de rendimiento a medida que el número de proyectos se aproxima a 300. Algunas experiencias, como la conexión a un proyecto desde Visual Studio, pueden degradarse.

Al migrar a Azure DevOps Services, observe un límite máximo de 1000 proyectos. Si la colección supera este límite, divida la colección o elimine proyectos anteriores. Para más información, consulte Migración de datos de Azure DevOps Server a Azure DevOps Services.

Personalización de procesos

Hay muchos límites en el número de objetos que puede definir para un proceso. Para más información, consulte Personalización de la experiencia de seguimiento del trabajo.

En la tabla siguiente se muestra el número máximo de objetos que puede definir para los modelos de proceso herencia y XML hospedado. También se pueden aplicar límites prácticos.

Object Herencia XML hospedado
Número de procesos por organización 128 64
Tipos de elementos de trabajo por proceso 64 64
Campos por organización 8192 8192
Campos por proceso 1024 1024
Campos por tipo de elemento de trabajo 1024 1024
Listas de selección por organización 2048 -
Elementos de lista desplegable por lista 2048 2048
Longitud de caracteres del elemento Picklist 256 -
Estados de flujo de trabajo por tipo de elemento de trabajo 32 16
Páginas (pestañas) por tipo de elemento de trabajo 16 16
Grupos por página 32 32
Reglas por tipo de elemento de trabajo 1024 1024
Acciones por tipo de elemento de trabajo 1024 1024
Acciones por regla 10 10
Niveles de trabajo pendiente de cartera por proceso 5 5
Categorías por proceso - 32
Tamaño de datos adjuntos del elemento de trabajo 60 MB 60 MB

Nota:

Para el modelo de proceso XML hospedado, puede definir aproximadamente 10 000 elementos en todas las listas globales especificadas en todas las WIT. Para conocer otras restricciones y requisitos de conformidad del modelo de proceso XML hospedado, consulte Personalización de un proceso al usar XML hospedado.

En la tabla siguiente se muestra el número máximo de objetos que puede definir para los modelos de proceso XML heredados y locales. También se pueden aplicar límites prácticos.

Object Herencia XML local
Número de procesos por colección 64 64
Tipos de elementos de trabajo por proceso 64 64
Campos por colección 8192 1024
Campos por proceso 1024 1024
Campos por tipo de elemento de trabajo 1024 1024
Listas de selección por colección 1024 N/D
Elementos de lista desplegable por lista 2048 2048
Longitud de caracteres del elemento Picklist 256 N/D
Estados de flujo de trabajo por tipo de elemento de trabajo 32 16
Reglas por tipo de elemento de trabajo 1024 1024
Niveles de trabajo pendiente de cartera por proceso 5 5
Categorías por proceso N/D 32
Listas globales por proceso N/D 256
Elementos de lista por lista global N/D 1024

Nota:

Para el modelo de proceso XML local, puede definir un total aproximado de 10 000 elementos para todas las listas globales especificadas en todas las WIT.

Límites prácticos

Para minimizar los problemas de rendimiento, siga estas instrucciones:

  • Limite el número de campos personalizados que defina. Todos los campos personalizados contribuyen al total permitido para un proceso, recopilación u organización. Puede especificar diferentes comportamientos, como reglas y listas de selección, para el mismo campo en diferentes WIT.

  • Limite el número de reglas que defina para un WIT. Aunque puede crear varias reglas para un WIT, otras reglas pueden afectar negativamente al rendimiento cuando los usuarios agregan o modifican elementos de trabajo.

  • Limite el número de WIT personalizados que defina.

  • Limite el número de campos que se pueden notificar que defina. Los campos que se pueden notificar pueden afectar al rendimiento del almacenamiento de datos.

La validación de reglas de elemento de trabajo supera los límites de SQL

Se define una expresión SQL única por proyecto para validar los elementos de trabajo cada vez que se crean o actualizan. Esta expresión crece con el número de reglas especificadas para todos los tipos de elementos de trabajo del proyecto.

Cada calificador de comportamiento de un campo aumenta el número de subexpresiones. Reglas anidadas, reglas que solo se aplican en una transición o reglas condicionadas al valor de otro campo agregan más condiciones a una IF instrucción.

Cuando los usuarios guardan elementos de trabajo, el sistema valida todas las reglas asociadas a los campos de ese tipo de elemento de trabajo. Una vez que la expresión alcanza un tamaño o complejidad determinados, SQL ya no puede evaluarlo de forma eficaz y puede generar un error. Para resolver este error, quite algunos WIT o elimine algunas reglas.

Límites de frecuencia

Azure DevOps Services, como muchas soluciones de software como servicio, usa multiinquilino para reducir los costos y mejorar la escalabilidad y el rendimiento. Para garantizar un buen rendimiento y minimizar el riesgo de interrupciones, Azure DevOps Services limita los recursos que los usuarios pueden consumir y el número de solicitudes que pueden realizar en determinados comandos. Cuando se superan estos límites, es posible que las solicitudes posteriores se retrasen o bloqueen.

La mayoría de los límites de frecuencia se alcanzan a través de llamadas api REST o consultas nooptimizadas. Para obtener más información, consulte Límites de velocidad y Procedimientos recomendadospara evitar alcanzar los límites de velocidad.

Límites de migración e importación

Al migrar de Azure DevOps Server local a Azure DevOps Services, es posible que encuentre los siguientes problemas de tamaño:

  • Tamaño de la base de datos que supera el tamaño recomendado
  • Tamaño de tabla mayor que supera el tamaño recomendado
  • Tamaño de metadatos de base de datos que supera el tamaño admitido

Para más información, consulte Migración de datos de Azure DevOps Server a Azure DevOps Services y Solución de errores de importación y migración.