Acompanhamento de trabalho, processo e limites de projeto
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Este artigo define os limites operacionais e de objeto colocados nas operações de controle de trabalho e na personalização do controle de trabalho. Além dos limites rígidos especificados em objetos selecionados, alguns limites práticos se aplicam. Ao personalizar tipos de item de trabalho (WITs), considere os limites colocados nos objetos.
Itens de trabalho e consultas
Ao definir itens de trabalho ou executar consultas, os seguintes limites operacionais se aplicam.
Objeto | Limite |
---|---|
Anexos adicionados a um item de trabalho | 100 |
Tamanho do anexo | 60 MB |
Campo de texto longo | 1 M de caracteres |
Tempo de execução da consulta | 30 segundos |
Resultados da consulta | 20.000 itens |
Comprimento da consulta | 32.000 caracteres |
Consultas compartilhadas em uma pasta | 999 consultas |
Links de item de trabalho atribuídos a um item de trabalho | 1.000 |
Marcas de item de trabalho atribuídas a um item de trabalho | 100 |
Revisões de item de trabalho (API REST) | 10.000 |
Consultas favoritas por projeto | 200 consultas |
Um limite de revisão de item de trabalho de 10.000 está em vigor para atualizações feitas por meio da API REST para o Azure DevOps Services. Esse limite restringe as atualizações da API REST, no entanto, as atualizações do portal da Web não são afetadas.
Objeto | Limite |
---|---|
Campo de texto longo | 1 M de caracteres |
Marcas de item de trabalho atribuídas a um item de trabalho | 100 |
Links de item de trabalho atribuídos a um item de trabalho | 1.000 |
Anexos adicionados a um item de trabalho | 100 |
Tamanho do anexo | 4 MB a 2 GB |
Tempo de execução da consulta | 6 minutos |
Resultados da consulta | 20.000 itens |
Comprimento da consulta | 32.000 caracteres |
Consultas compartilhadas em uma pasta | 999 consultas |
Consultas favoritas por projeto | 200 consultas |
O tamanho máximo padrão do anexo é de 4 MB. Você pode alterar o tamanho máximo até 2 GB.
Para melhorar o desempenho da consulta, consulte Definir uma consulta/Práticas recomendadas.
Backlogs, quadros, painéis e equipes
Ao trabalhar com equipes, tags de item de trabalho, listas de pendências e quadros, os seguintes limites operacionais de exibição e objeto se aplicam.
Interface do usuário | Limite |
---|---|
Pendências | 10.000 itens de trabalho |
Boards | 1.000 cartões (excluindo os cartões nas categorias de estado de fluxo de trabalho Proposto e Concluído) |
Quadro de tarefas | 1.000 tarefas |
Caminhos de área | 10.000 por projeto |
Profundidade do Caminho da Área | 14 |
Caminhos de área por equipe | 300 |
Caminhos de iteração | 10.000 por projeto |
Profundidade do caminho de iteração | 14 |
Caminhos de iteração por equipe | 300 |
Painéis do projeto | 500 por projeto |
Painéis da equipe | 500 por equipe |
Teams | 5.000 por projeto |
Marcas de item de trabalho | 150.000 definições de tags por organização ou coleção |
Planos de entrega por projeto | 1.000 |
Modelos por tipo de item de trabalho | 100 |
Cada lista de pendências pode exibir até 10.000 itens de trabalho. Esse é um limite para o que a lista de pendências pode exibir, não um limite para o número de itens de trabalho que você pode definir. Se a lista de pendências exceder esse limite, talvez você deva adicionar uma equipe e mover alguns dos itens de trabalho para a lista de pendências da outra equipe.
Observações adicionais:
- Os itens de trabalho concluídos ou fechados não são exibidos nas listas de pendências e quadros depois que a Data Alterada for maior que um ano. Você ainda pode listar esses itens usando uma consulta. Se você quiser que eles apareçam em uma lista de pendências ou quadro, então você pode fazer uma pequena alteração neles que redefine o relógio para exibição.
- Evite aninhar itens de lista de pendências do mesmo tipo. Para saber mais, consulte Corrigir problemas de reordenação e aninhamento.
- Evite atribuir os mesmos caminhos de área a mais de uma equipe. Para saber mais, consulte Limitações das exibições do quadro Kanban de várias equipes.
- Por padrão, os limites de item de trabalho podem ser inicialmente configurados para valores mais baixos.
Ao trabalhar com equipes, tags de item de trabalho, listas de pendências e quadros, os seguintes limites operacionais se aplicam. Limites padrão e máximo.
Interface do usuário | Limite |
---|---|
Pendências | 999 itens de trabalho |
Boards | 400 cartões |
Dashboards por projeto | 500 |
Quadro de tarefas | 800 itens de trabalho |
Teams | 5.000 por projeto |
Marcas de item de trabalho | 150.000 definições de tag por projeto |
Modelos por tipo de item de trabalho | 100 |
Cada lista de pendências pode exibir até 999 itens de trabalho. Se a lista de pendências exceder esse limite, talvez você deva adicionar uma equipe e mover alguns dos itens de trabalho para a lista de pendências da outra equipe.
Observações adicionais:
- Evite aninhar itens de lista de pendências do mesmo tipo. Para saber mais, consulte Corrigir problemas de reordenação e aninhamento.
- Evite atribuir os mesmos caminhos de área a mais de uma equipe. Para saber mais, consulte Limitações das exibições do quadro Kanban de várias equipes.
Para o modelo de processo XML local, você pode modificar os limites da lista de pendências e do quadro de tarefas editando o arquivo ProcessConfiguration.xml. Para obter detalhes, consulte Referência do elemento XML de configuração do processo.
Projetos
Os Serviços de DevOps do Azure limitam cada organização a 1000 projetos por organização, um aumento em relação ao limite anterior de 300 projetos.
Observação
Acima de 300 projetos, certas experiências, como conectar-se a um projeto do Visual Studio, podem começar a degradar. Para o Servidor de DevOps do Azure local, não há limites rígidos para o número de projetos. No entanto, você pode encontrar problemas de desempenho se o número de projetos se aproximar de 300. Se você planeja migrar sua coleção local para os Serviços de DevOps do Azure, precisará observar o limite máximo de 1000 projetos. Se sua coleção tiver mais de 1000 projetos, você precisará dividir a coleção ou excluir projetos mais antigos.
Para obter mais informações, confira Migrar dados do Azure DevOps Server para o Azure DevOps Services.
Personalização do processo
Vários limites são impostos ao número de objetos que você pode definir para um processo. Para saber mais sobre modelos de processo, consulte Personalizar sua experiência de controle de trabalho.
A tabela a seguir lista o número máximo de objetos que você pode definir para os modelos de processo Herança e XML hospedado. Embora estes representem limites rígidos, limites práticos também podem ser aplicados.
Objeto | Herança | XML hospedado |
---|---|---|
Número de processos que você pode ter em uma organização | 128 | 64 |
Tipos de itens de trabalho definidos para um processo | 64 | 64 |
Campos definidos para uma organização | 8192 | 8192 |
Campos definidos para um processo | 1024 | 1024 |
Campos definidos para um tipo de item de trabalho | 1024 | 1024 |
Listas de opções definidas para uma organização ou coleção | 2048 | - |
Itens da lista de opções definidos para uma lista | 2.048 | 2.048 |
Comprimento do caractere do item da lista de opções | 256 | - |
Estados do fluxo de trabalho definidos para um tipo de item de trabalho | 32 | 16 |
Regras definidas para um tipo de item de trabalho | 1024 | 1024 |
Ações definidas para uma regra | 10 | 10 |
Níveis de carteira de pendências definidos para um processo | 5 | 5 |
Categorias definidas para um processo | - | 32 |
Listas globais definidas para um processo | - | 256 |
Listar itens definidos em uma lista global | - | 1024 |
Tamanho do anexo do item de trabalho | 60 MB | 60 MB |
Para obter restrições adicionais e requisitos de conformidade do modelo de processo Hosted XML, consulte Personalizar um processo ao usar Hosted XML.
Observação
Para o modelo de processo XML hospedado, você pode definir um total aproximado de 10 mil itens para todas as listas globais especificadas em todos os WITs.
A tabela a seguir lista o número máximo de objetos que você pode definir para os modelos de processo XML local e Herança. Embora estes representem limites rígidos, limites práticos também podem ser aplicados.
Objeto | Herança | XML local |
---|---|---|
Número de processos que você pode ter em uma organização | 64 | 64 |
Tipos de itens de trabalho definidos para um processo | 64 | 64 |
Campos definidos para uma coleção | 8192 | 1024 |
Campos definidos para um processo | 1024 | 1024 |
Campos definidos para um tipo de item de trabalho | 1024 | 1024 |
Listas de opções definidas para uma coleção | 1024 | N/D |
Itens da lista de opções definidos para uma lista | 2.048 | 2.048 |
Comprimento do caractere do item da lista de opções | 256 | N/D |
Estados do fluxo de trabalho definidos para um tipo de item de trabalho | 32 | 16 |
Regras definidas para um tipo de item de trabalho | 1024 | 1024 |
Níveis de carteira de pendências definidos para um processo | 5 | 5 |
Categorias definidas para um processo | N/D | 32 |
Listas globais definidas para um processo | N/D | 256 |
Listar itens definidos em uma lista global | N/D | 1024 |
Observação
Para o modelo de processo XML local, você pode definir um total aproximado de 10 mil itens para todas as listas globais especificadas em todos os WITs.
Limites práticos
Recomendamos que você considere as seguintes diretrizes para minimizar os problemas de desempenho.
- Minimize o número de campos personalizados que você definir. Todos os campos personalizados contribuem para o total permitido para um processo, coleção ou organização. Observe que você pode especificar um comportamento diferente para o mesmo campo em um WIT diferente. Ou seja, você pode especificar diferentes regras, listas de opções e muito mais.
- Minimize o número de regras definidas para um WIT. Embora você possa criar várias regras para um WIT, as regras de adição podem afetar negativamente o desempenho quando um usuário adiciona e modifica itens de trabalho. Quando os usuários salvam itens de trabalho, o sistema valida todas as regras associadas aos campos para seu tipo de item de trabalho. Sob certas condições, a expressão de validação de regras é muito complexa para ser avaliada pelo SQL.
- Minimize o número de WITs personalizados que você definir.
- Minimize o número de campos personalizados que você definir. Todos os campos personalizados contribuem para o total permitido para um processo, coleção ou organização. Observe que você pode especificar um comportamento diferente para o mesmo campo em um WIT diferente. Ou seja, você pode especificar diferentes regras, listas de opções e muito mais.
- Minimize o número de regras definidas para um WIT. Embora você possa criar várias regras para um WIT, as regras de adição podem afetar negativamente o desempenho quando um usuário adiciona e modifica itens de trabalho. Quando os usuários salvam itens de trabalho, o sistema valida todas as regras associadas aos campos para seu tipo de item de trabalho. Sob certas condições, a expressão de validação de regras é muito complexa para ser avaliada pelo SQL.
- Minimize o número de WITs personalizados que você definir.
- Minimize o número de campos relatáveis que você definir. Os campos relatáveis afetam o desempenho do seu data warehouse.
Observação
A validação de regras de item de trabalho excede os limites SQL: uma única expressão SQL é definida por projeto para validar itens de trabalho sempre que eles são criados ou atualizados. Essa expressão cresce com o número de regras especificadas para todos os tipos de item de trabalho definidos para o projeto. Cada qualificador comportamental especificado para um campo resulta em um aumento no número de subexpressões. Regras aninhadas, regras que se aplicam somente em uma transição ou condicionadas ao valor de algum outro campo, fazem com que mais condições sejam adicionadas a uma instrução SE. Quando a expressão atinge um determinado tamanho ou complexidade, o SQL não pode mais avaliá-la e gera um erro. Remover alguns WITs ou eliminar algumas regras, pode resolver o erro.
Limites de taxa
Para reduzir custos e melhorar a escalabilidade e o desempenho, os Serviços de DevOps do Azure, como muitas soluções de Software como Serviço, usam multilocação. Para garantir um bom desempenho e reduzir a probabilidade de paralisações, os Serviços de DevOps do Azure limitam os recursos que os indivíduos podem consumir e o número de solicitações que podem fazer a determinados comandos. Quando esses limites são excedidos, as solicitações subsequentes podem ser atrasadas ou bloqueadas.
A maioria dos limites de taxa é atingida por meio de chamadas de API REST ou consultas não otimizadas. Para saber mais, leia os seguintes artigos:
Migrar e importar limites
Ao determinar a migração do local para os Serviços de DevOps do Azure, há vários limites de tamanho que você pode encontrar. Esses limites incluem:
- O tamanho do banco de dados está acima do tamanho recomendado
- O maior tamanho da tabela está acima do tamanho recomendado
- O tamanho dos metadados do banco de dados está acima do tamanho suportado
Para saber mais, consulte Migrar dados do Servidor de DevOps do Azure para os Serviços de DevOps do Azure e Solucionar problemas de erros de importação e migração.
Artigos relacionados
Recursos relacionados
Comentários
https://aka.ms/ContentUserFeedback.
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulteEnviar e exibir comentários de