Seguimiento del trabajo, proceso y límites del proyecto
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
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 objetos específicos, se aplican algunos 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 consultas en ejecución, tenga en cuenta 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 | Caracteres de 1 M |
| 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 |
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 las actualizaciones del portal web no se ven afectadas.
| Object | Límite |
|---|---|
| Campo de texto largo | Caracteres de 1 M |
| 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, se aplican 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. Accesible en el nivel de proyecto y cualquier persona con acceso al proyecto puede usar. |
| Paneles de equipo | 500 por equipo. Específico del equipo y usado para realizar un seguimiento de métricas y datos específicos del 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. Este límite se aplica a lo que puede mostrar el trabajo pendiente, no al número de elementos de trabajo que puede definir, ya que no hay ningún límite específico. Si el trabajo pendiente supera este límite, 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 de los paneles, consulte los pasos siguientes para administrar y limpiar los paneles:
- Revisar el uso: identifique los paneles que ya no están en uso o que están duplicados. Para ello, compruebe la última fecha de acceso o consulte con los miembros del equipo.
- Consolidar paneles: combine paneles similares para reducir el número total. Esto se puede hacer agregando varios widgets a un único panel.
- Archivar paneles antiguos: si ya no se necesitan determinados paneles, pero desea conservar los datos, considere la posibilidad de exportar los datos y archivar los paneles.
- Usar la característica Seguimiento de límite de objetos: proporciona 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.
Otras notas:
- Los elementos de trabajo completados o cerrados no se muestran en trabajos pendientes y paneles una vez que su fecha de cambio sea anterior a un año. Puede enumerar estos elementos mediante una consulta. Para que aparezcan en un trabajo pendiente o en un panel, realice un cambio menor para restablecer el reloj de pantalla.
- 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 del panel de varios equipos.
- De forma predeterminada, los límites de elementos de trabajo pueden establecerse en valores inferiores inicialmente.
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, considere la posibilidad de crear un equipo y mover algunos de los elementos de trabajo al trabajo pendiente del nuevo equipo.
Otras notas:
- 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 varios equipos. Para obtener más información, consulte Limitaciones de las vistas del panel 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 ProcessConfiguration.xml archivo. 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, 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, pero pueden surgir problemas de rendimiento a medida que el número de proyectos se aproxima a 300. Al migrar a Azure DevOps Services, observe el 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
Muchos límites se imponen al número de objetos que se pueden 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. Aunque estos límites son 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 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 conocer otras restricciones 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 aproximadamente 10 000 elementos en 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 heredados y locales. Aunque estos límites son 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.
Límites prácticos
Para minimizar los problemas de rendimiento, se recomienda seguir esta guía:
- 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. Cuando los usuarios guardan elementos de trabajo, el sistema valida todas las reglas asociadas a los campos de ese tipo de elemento de trabajo. En algunos casos, la expresión de validación de reglas podría ser demasiado compleja para que SQL se evalúe de forma eficaz.
- Limite el número de WIT personalizados que defina.
- 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. Cuando los usuarios guardan elementos de trabajo, el sistema valida todas las reglas asociadas a los campos de ese tipo de elemento de trabajo. En algunos casos, la expresión de validación de reglas podría ser demasiado compleja para que SQL se evalúe de forma eficaz.
- 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.
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 especificadas para todos los tipos de elementos de trabajo del proyecto. Cada calificador de comportamiento de un campo aumenta el número de subexpresiones. Las reglas anidadas, las reglas que se aplican solo en una transición o las reglas condicionadas en el valor de otro campo agregan más condiciones a una instrucción IF. Una vez que la expresión alcanza un tamaño o complejidad determinados, SQL ya no puede evaluarlo y genera un error. Para resolver este error, quite algunos WIT o elimine algunas reglas.
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 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 recomendados (para evitar alcanzar los límites de velocidad).
Migración e importación de límites
Al migrar de un entorno local a Azure DevOps Services, es posible que encuentre varios límites de tamaño, entre los que se incluyen:
- 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.