Seguimiento del trabajo, proceso y límites del proyecto

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

En este artículo se definen los límites operativos y de objetos colocados en las operaciones de seguimiento del trabajo y la personalización del seguimiento del trabajo. Además de los límites estrictos especificados en los objetos seleccionados, se aplican ciertos límites prácticos. Al personalizar los tipos de elementos de trabajo (WIT), tenga en cuenta los límites colocados en los objetos.

Elementos de trabajo y consultas

Al definir elementos de trabajo o ejecutar consultas, se aplican los siguientes límites operativos.

Object Límite
Datos adjuntos agregados a un elemento de trabajo 100
Tamaño de datos adjuntos 60 MB
Campo de texto largo 1 M 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 en una carpeta 999 consultas
Vínculos de elemento de trabajo asignados a un elemento de trabajo 1,000
Etiquetas de elemento de trabajo asignadas a un elemento de trabajo 100
Revisiones de elementos de trabajo (API REST) 10,000
Consultas favoritas por proyecto 200 consultas

El límite de revisión de elementos de trabajo que está en vigor para las actualizaciones realizadas a través de la API de REST para Azure DevOps Services es de 10 000. Este límite restringe las actualizaciones de la API de REST, sin embargo, las actualizaciones del portal web no se ven afectadas.

Object Límite
Campo de texto largo 1 M caracteres
Etiquetas de elemento de trabajo asignadas a un elemento de trabajo 100
Vínculos de elemento de trabajo asignados a un elemento de trabajo 1,000
Datos adjuntos agregados a un 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 en una 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 mejorar el rendimiento de las consultas, consulte Definición de una consulta o procedimientos recomendados.

Trabajos pendientes, paneles, paneles y equipos

Al trabajar con equipos, se aplican etiquetas de elementos de trabajo, trabajos pendientes y paneles, los siguientes límites de visualización operativa y objetos.

Interfaz de usuario Límite
Trabajos pendientes 10 000 elementos de trabajo
Boards 1000 tarjetas (excepto esas tarjetas en las categorías de estado de flujo de trabajo Propuesto y Completado)
Panel de tareas 1000 tareas
Rutas de acceso al área 10 000 por proyecto
Profundidad del trazado del área 14
Rutas de acceso de área por equipo 300
Rutas de acceso de iteración 10 000 por proyecto
Profundidad de la ruta de acceso de iteración 14
Rutas de acceso de iteración por equipo 300
Paneles del proyecto 500 por proyecto
Paneles de equipo 500 por equipo
Teams 5000 por proyecto
Etiquetas de elemento de trabajo 150 000 definiciones de etiquetas por organización o colección
Planes de entrega por proyecto 1,000
Plantillas por tipo de elemento de trabajo 100

Cada trabajo pendiente puede mostrar hasta 10 000 elementos de trabajo. Se trata de un límite en lo que puede mostrar el trabajo pendiente, no un límite en el número de elementos de trabajo que puede definir. Si el trabajo pendiente supera este límite, es posible que quiera considerar la posibilidad de agregar un equipo y mover algunos de los elementos de trabajo al trabajo pendiente del otro equipo.

Notas adicionales:

  • Los elementos de trabajo completados o cerrados no se muestran en los trabajos pendientes y los paneles una vez que ha transcurrido un año desde su fecha de modificación. Puede enumerar estos elementos mediante una consulta. Si quiere que aparezcan en un trabajo pendiente o en un panel, puede realizar un cambio menor en ellos que restablezca el reloj para su presentación.
  • Evite anidar elementos de trabajo pendiente del mismo tipo. Para 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 del panel Kanban de varios equipos.
  • De forma predeterminada, los límites de elementos de trabajo se pueden configurar inicialmente para reducir los valores.

Al trabajar con equipos, se aplican etiquetas de elementos de trabajo, trabajos pendientes y paneles, los siguientes límites operativos. Límites predeterminados y máximos.

Interfaz de usuario Límite
Trabajos pendientes 999 elementos de trabajo
Boards 400 tarjetas
Paneles por proyecto 500
Panel de tareas 800 elementos de trabajo
Teams 5000 por proyecto
Etiquetas de elemento de trabajo 150 000 definiciones de etiquetas por proyecto
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, es posible que quiera considerar la posibilidad de agregar un equipo y mover algunos de los elementos de trabajo al trabajo pendiente del otro equipo.

Notas adicionales:

  • Evite anidar elementos de trabajo pendiente del mismo tipo. Para 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 del panel Kanban de varios equipos.

Para el modelo de proceso XML local, puede modificar los límites del trabajo pendiente y del panel de tareas editando el archivo ProcessConfiguration.xml. Para obtener más información, consulte Process configuration XML element reference (Referencia del elemento XML de configuración del proceso).

Proyectos

Azure DevOps Services limita cada organización a 1000 proyectos por organización, lo que aumenta el límite anterior de 300 proyectos.

Nota:

Más de 300 proyectos de determinadas experiencias, como la conexión a un proyecto desde Visual Studio, puede empezar a degradarse. En el caso de Azure DevOps Server local, no hay límites estrictos para el número de proyectos. Sin embargo, puede encontrar problemas de rendimiento si el número de proyectos se aproxima a 300. Si planea migrar la colección local a Azure DevOps Services, deberá observar el límite máximo de 1000 proyectos. Si la colección tiene más de 1000 proyectos, deberá dividir la colección o eliminar proyectos anteriores.

Para más información, consulte Migración de datos de Azure DevOps Server a Azure DevOps Services.

Personalización de procesos

Se imponen varios límites al número de objetos que se pueden definir para un proceso. Para obtener información sobre los modelos de proceso, 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 De herencia y XML hospedado. Aunque estos representan límites estrictos, también se pueden aplicar límites prácticos.

Object Herencia XML hospedado
Número de procesos que puede tener en una organización 128 64
Tipos de elementos de trabajo definidos para un proceso 64 64
Campos definidos para una organización 8192 8192
Campos definidos para un proceso 1024 1024
Campos definidos para un tipo de elemento de trabajo 1024 1024
Listas de selección definidas para una organización o colección 2048 -
Elementos de lista desplegable definidos para una lista 2048 2048
Longitud de caracteres del elemento Picklist 256 -
Estados de flujo de trabajo definidos para un tipo de elemento de trabajo 32 16
Reglas definidas para un tipo de elemento de trabajo 1024 1024
Acciones definidas para una regla 10 10
Niveles de trabajo pendiente de cartera definidos para un proceso 5 5
Categorías definidas para un proceso - 32
Listas globales definidas para un proceso - 256
Enumerar elementos definidos dentro de una lista global - 1024
Tamaño de datos adjuntos del elemento de trabajo 60 MB 60 MB

Para obtener restricciones adicionales y requisitos de conformidad del modelo de proceso XML hospedado, consulte Personalización de un proceso al usar XML hospedado.

Nota:

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

En la tabla siguiente se muestra el número máximo de objetos que puede definir para los modelos de proceso XML de herencia y locales. Aunque estos representan límites estrictos, también se pueden aplicar límites prácticos.

Object Herencia XML local
Número de procesos que puede tener en una organización 64 64
Tipos de elementos de trabajo definidos para un proceso 64 64
Campos definidos para una colección 8192 1024
Campos definidos para un proceso 1024 1024
Campos definidos para un tipo de elemento de trabajo 1024 1024
Listas de selección definidas para una colección 1024 N/D
Elementos de lista desplegable definidos para una lista 2048 2048
Longitud de caracteres del elemento Picklist 256 N/D
Estados de flujo de trabajo definidos para un tipo de elemento de trabajo 32 16
Reglas definidas para un tipo de elemento de trabajo 1024 1024
Niveles de trabajo pendiente de cartera definidos para un proceso 5 5
Categorías definidas para un proceso N/D 32
Listas globales definidas para un proceso N/D 256
Enumerar elementos definidos dentro de una 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.

En la tabla siguiente se muestra el número máximo de objetos que puede definir para el modelo de proceso XML local. Aunque estos representan límites estrictos, se pueden aplicar límites prácticos.

Object XML local
Número de procesos que puede tener en una organización 64
Tipos de elementos de trabajo definidos para un proceso 64
Campos definidos para una colección 1024
Campos definidos para un proceso 1024
Campos definidos para un tipo de elemento de trabajo 1024
Listas de selección definidas para una colección N/D
Elementos de lista desplegable definidos para una lista 2048
Longitud de caracteres del elemento Picklist N/D
Estados de flujo de trabajo definidos para un tipo de elemento de trabajo 16
Reglas definidas para un tipo de elemento de trabajo 1024
Niveles de trabajo pendiente de cartera definidos para un proceso 5
Categorías definidas para un proceso 32
Listas globales definidas para un proceso 256
Enumerar elementos definidos dentro de una lista global 1024
Tamaño de la plantilla de proceso importada 2 GB

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

Se recomienda tener en cuenta las instrucciones siguientes para minimizar los problemas de rendimiento.

  • Minimice el número de campos personalizados que defina. Todos los campos personalizados contribuyen al total permitido para un proceso, recopilación u organización. Tenga en cuenta que puede especificar un comportamiento diferente para el mismo campo en otro WIT. Es decir, puede especificar reglas, listas de selección y mucho más.
  • Minimice el número de reglas que defina para un WIT. Aunque puede crear varias reglas para un WIT, las reglas de adición pueden afectar negativamente al rendimiento cuando un usuario agrega y modifica elementos de trabajo. Cuando los usuarios guardan elementos de trabajo, el sistema valida todas las reglas asociadas a los campos para su tipo de elemento de trabajo. En determinadas condiciones, la expresión de validación de la regla es demasiado compleja para que SQL la evalúe.
  • Minimice el número de WIT personalizados que defina.
  • Minimice el número de campos personalizados que defina. Todos los campos personalizados contribuyen al total permitido para un proceso, recopilación u organización. Tenga en cuenta que puede especificar un comportamiento diferente para el mismo campo en otro WIT. Es decir, puede especificar reglas, listas de selección y mucho más.
  • Minimice el número de reglas que defina para un WIT. Aunque puede crear varias reglas para un WIT, las reglas de adición pueden afectar negativamente al rendimiento cuando un usuario agrega y modifica elementos de trabajo. Cuando los usuarios guardan elementos de trabajo, el sistema valida todas las reglas asociadas a los campos para su tipo de elemento de trabajo. En determinadas condiciones, la expresión de validación de la regla es demasiado compleja para que SQL la evalúe.
  • Minimice el número de WIT personalizados que defina.
  • Minimice el número de campos notificables que defina. Los campos que se pueden notificar afectan al rendimiento del almacenamiento de datos.

Nota:

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 que se especifican para todos los tipos de elementos de trabajo definidos para el proyecto. Cada calificador de comportamiento especificado para un campo da como resultado un aumento en el número de subexpresiones. Las reglas anidadas, las reglas que se aplican solo en una transición o condicionadas en el valor de algún otro campo, hacen que se agreguen más condiciones a una instrucción IF. Una vez que la expresión alcanza un tamaño o complejidad determinado, SQL no puede evaluarla más y genera un error. La eliminación de algunas WIT o la eliminación de algunas reglas puede resolver el error.

Límites de frecuencia

Para reducir los costos y mejorar la escalabilidad y el rendimiento, Azure DevOps Services, como muchas soluciones de software como servicio, usa servicios multiinquilino. Para garantizar un buen rendimiento y reducir la probabilidad 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, las solicitudes posteriores pueden retrasarse o bloquearse.

La mayoría de los límites de frecuencia se alcanzan a través de llamadas a la API REST o consultas no optimizadas. Para más información, vea los siguientes artículos:

Migración e importación de límites

Al determinar cómo migrar de un entorno local a Azure DevOps Services, hay varios límites de tamaño que puede encontrar. Estos límites son:

  • El tamaño de la base de datos está por encima del tamaño recomendado
  • El tamaño de tabla más grande está por encima del tamaño recomendado
  • El tamaño de los metadatos de la base de datos está por encima del 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.