Aplicar regras aos estados do fluxo de trabalho (processo de herança)
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Depois de adicionar ou modificar seus estados de fluxo de trabalho para um tipo de item de trabalho, convém definir uma ou mais regras que são aplicadas dependendo da alteração do estado do fluxo de trabalho. A adição de regras aos estados de fluxo de trabalho dá suporte aos seguintes cenários:
- Dar suporte a um processo de aprovação
- Impedir que usuários não autorizados configurem um estado inválido
- Tornar um campo obrigatório ou somente leitura ou outro valor com base em alterações de estado
- Restringir a transição de um estado para outro
- Restringir ou permitir transições de estado para usuários ou grupos específicos
- Manter um processo de fluxo de trabalho controlado para dar suporte aos requisitos de auditoria
- Automatizar o fechamento de itens de trabalho pai
- Dar suporte a um processo de aprovação
- Impedir que usuários não autorizados configurem um estado inválido
- Tornar um campo obrigatório ou somente leitura ou outro valor com base em alterações de estado
- Restringir a transição de um estado para outro
- Automatizar o fechamento de itens de trabalho pai
- Dar suporte a um processo de aprovação
- Tornar um campo obrigatório ou somente leitura ou outro valor com base em alterações de estado
- Automatizar o fechamento de itens de trabalho pai
Examine este artigo para entender como definir regras que se aplicam quando você altera um estado de fluxo de trabalho.
- Entender os tipos de regras de fluxo de trabalho
- Estado do fluxo de trabalho e limites de regra e práticas recomendadas
- Definir um valor de campo ou tornar um campo somente leitura ou obrigatório com base na seleção de Estado
- Restringir as transições de estado
- Restringir ou permitir transições de estado para usuários ou grupos específicos
- Automatizar transições de estado de itens de trabalho pai
- Entender os tipos de regras de fluxo de trabalho
- Estado do fluxo de trabalho e limites de regra e práticas recomendadas
- Definir um valor de campo ou tornar um campo somente leitura ou obrigatório com base na seleção de Estado
- Restringir as transições de estado
- Automatizar transições de estado de itens de trabalho pai
- Entender os tipos de regras de fluxo de trabalho
- Estado do fluxo de trabalho e limites de regra e práticas recomendadas
- Definir um valor de campo ou tornar um campo somente leitura ou obrigatório com base na seleção de Estado
- Automatizar transições de estado de itens de trabalho pai
Importante
Este artigo se aplica a Azure DevOps Services e Azure DevOps Server 2019 e versões posteriores. Para personalizar qualquer projeto definido em uma coleção para o TFS 2018 ou anterior, consulte Modelo de processo XML local.
Importante
Você só pode usar o modelo de processo de herança para projetos definidos em uma coleção de projetos configurada para dar suporte ao modelo de processo de herança. Se sua coleção local estiver configurada para usar o modelo de processo XML local, você só poderá usar esse modelo de processo para personalizar a experiência de acompanhamento de trabalho. Para saber mais, confira Personalizar o acompanhamento de trabalho, Escolha o modelo de processo para sua coleção de projetos.
Para personalizar qualquer projeto definido em uma coleção para o TFS 2018 ou anterior, consulte Modelo de processo XML local.
Regras de fluxo de trabalho
A tabela a seguir indica os três grupos de regras de fluxo de trabalho que você pode definir. O primeiro grupo aplica ações padrão quando um item de trabalho é criado, em um estado selecionado, ou é movido de um estado para outro. Essas ações padrão definem o valor de um campo ou tornam um campo somente leitura ou obrigatório. Nesse grupo, você pode especificar uma ou duas condições e várias ações.
O segundo e o terceiro grupos dão suporte à restrição de transições de estado. Esses dois grupos permitem que você especifique uma e apenas uma condição indicando o estado para o qual um item de trabalho foi movido. Em seguida, você pode especificar uma ou mais ações para restringir a transição desse estado para outros estados.
A tabela a seguir indica os dois grupos de regras de fluxo de trabalho que você pode definir. O primeiro grupo aplica ações padrão quando um item de trabalho é criado, em um estado selecionado, ou é movido de um estado para outro. Essas ações padrão definem o valor de um campo ou tornam um campo somente leitura ou obrigatório. Nesse grupo, você pode especificar uma ou duas condições e várias ações.
O segundo grupo dá suporte à restrição de transições de estado. Neste segundo grupo, você pode especificar uma e apenas uma condição indicando o estado para o qual um item de trabalho foi movido. Em seguida, você pode especificar uma ou mais ações para restringir a transição desse estado para outros estados.
Observação
Determinados recursos exigem a instalação da atualização Azure DevOps Server 2020.1. Para obter mais informações, consulte Notas de versão da Atualização 1 RC1 do Azure DevOps Server 2020, Quadros.
As condições e as ações de fluxo de trabalho que você pode definir são ilustradas nas imagens a seguir. Você pode aplicar ações padrão quando um item de trabalho é criado, em um estado selecionado ou movido de um estado para outro. Essas ações padrão definem o valor de um campo ou tornam um campo somente leitura ou obrigatório. Para esse conjunto de regras, você pode especificar uma ou duas condições e várias ações.
Condição
Ações com suporte
Definir o valor do campo ou tornar somente leitura/obrigatório com base no Estado
Restringir uma transição com base no Estado
Ocultar campo ou tornar campo somente leitura ou obrigatório com base no Estado e na associação de usuário ou grupo
Com base na associação de usuários ou grupos, defina um atributo de campo ou restrinja uma transição de Estado
Observação
À medida que você personaliza um processo herdado, todos os projetos que usam esse processo são atualizados automaticamente para refletir as personalizações. Por esse motivo, recomendamos que você crie um processo de teste e um projeto de teste quando tiver várias personalizações a serem realizadas para testar as personalizações antes de implantá-las em sua organização. Para saber mais, confira Criar e gerenciar processos herdados.
Limites de estado e regra do fluxo de trabalho
A tabela a seguir resume o estado do fluxo de trabalho e os limites da regra para o processo de Herança.
Objeto | Limite de herança |
---|---|
Tipos de itens de trabalho definidos para um processo | 64 |
Estados do fluxo de trabalho definidos para um tipo de item de trabalho | 32 |
Regras definidas para um tipo de item de trabalho | 1024 |
Ao definir estados e regras de fluxo de trabalho, recomendamos que você considere as diretrizes a seguir para minimizar os problemas de desempenho.
- 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.
As regras de fluxo de trabalho são aplicadas ao adicionar ou modificar itens de trabalho por meio de qualquer uma das seguintes interfaces:
- Portal da Web: formulário de item de trabalho, atualizações em massa, atualizações no modo de exibição de consulta
- Portal da Web: quadro kanban ou quadro de tarefas, mova o item de trabalho para a coluna
- Visual Studio 2017 e versões anteriores, formulário de item de trabalho
- Formato de arquivo CSV: importação ou atualização em massa
- Excel: importação ou atualização em massa
- API REST: adicionar ou modificar itens de trabalho
Definir uma regra
Antes de definir uma regra com base nos estados de fluxo de trabalho, primeiro defina os seguintes elementos:
- O fluxo de trabalho afirma que você deseja, conforme descrito em Personalizar um fluxo de trabalho
- Se a regra exigir a especificação de um campo personalizado, adicione esse campo ao tipo de item de trabalho, conforme descrito em Adicionar e gerenciar campos
- Se a regra exigir que a especificação de um grupo de segurança conceda ou restrinja alterações com base na associação de usuários ou grupos, defina esse grupo de segurança conforme descrito em Adicionar ou remover usuários ou grupos, gerencie grupos de segurança.
Para obter as noções básicas de definição de regras, consulte Adicionar uma regra personalizada. Você deve atender aos pré-requisitos definidos nesse artigo.
Definir o valor do campo ou tornar o campo somente leitura ou obrigatório
Com o primeiro agrupamento de regras, você pode especificar uma ou duas condições e até 10 ações por regra.
Exemplo de como garantir a aprovação do líder da equipe antes do trabalho ativo
Neste exemplo, as equipes de desenvolvimento desejam garantir que nenhuma História de Usuário seja trabalhada até que seja aprovada por um líder de equipe. Os estados de fluxo de trabalho padrão estão em uso e apenas um único campo personalizado, Aprovado por e grupo de segurança, Grupo de Líderes de Equipe, são adicionados.
Estados de fluxo de trabalho padrão
Requisitos de regra
Para garantir a aprovação antes do trabalho ativo, as seguintes regras devem ser definidas:
- Exigir que o campo Aprovado por seja preenchido quando o Estado passar de Novo para Ativo
- Restringir usuários que não pertencem ao Grupo de Clientes Potenciais da Equipe para preencher o campo Aprovado por
- Desmarque o campo Aprovado por quando o Estado for movido para Novo ou Removido
Definições de função
Os requisitos de regra são convertidos nas quatro definições de regra a seguir.
Nome da regra
Condição
Ações
Aprovado por desmarcado quando Novo
Quando A work item state changes to New
Então Clear the value of Approved By
Aprovado por desmarcado quando removido
Quando A work item state changes to Removed
Então Clear the value of Approved By
Aprovado por somente leitura
Quando Current user is not member of group Team Leads Group
Então Make read-only Approved By
Aprovado por obrigatório
Quando A work item state changes from New to Active
Então Make required Approved By
Restringir as transições de estado
Ao especificar a condição, A work item state moved from ...
, você pode especificar apenas essa condição. Você pode especificar até 10 ações.
Observação
Esse recurso requer o Azure DevOps Server 2020.1 ou versão posterior.
Exemplo de restrição de transições de estado e estado aprovado
De acordo com a terminologia usada por um grupo de negócios, os seguintes estados de fluxo de trabalho são definidos para a História do Usuário. Os estados herdados Novo, Resolvido e Removido estão ocultos. Em vez disso, os Estados Propostos, Em Revisão e Recortados são usados. Além disso, três Estados adicionais são definidos: Investigar, Projetar e Aprovado. Esses Estados devem seguir a sequência, conforme mostrado na imagem a seguir.
Sem restrições, os usuários podem mover de um Estado para qualquer outro Estado, tanto para frente quanto para trás dentro da sequência.
Requisitos de regra
Para dar suporte a um fluxo de trabalho mais controlado, o grupo de negócios decidiu instituir regras que dariam suporte às seguintes transições de estado de encaminhamento e inverso no tipo de item de trabalho User Story.
- Proposta só pode mudar para Pesquisa e Corte
- A pesquisa só pode mudar para Design e Recortar
- O design só pode passar para Pesquisa, Aprovado e Recortar
- Aprovado só pode passar para Design, Ativo e Recortar
- Ativo só pode passar para Em Revisão
- Em Revisão só pode mover para Ativo (Trabalho adicional encontrado), Fechado ou Recortado
- Fechado pode passar para Pesquisa, Design, Ativo, Em Revisão (permite casos em que o usuário fechou o item de trabalho por erro)
- Recortar só pode passar para Proposta.
Observação
Ao restringir as transições de estado, considere os casos em que um usuário move um estado em erro. Você deseja que os usuários possam se recuperar normalmente.
Além disso, o grupo de negócios deseja aplicar regras para os campos necessários:
- Exigir que o campo Aprovado por seja preenchido quando o Estado passar de Aprovado para Ativo
- Permitir somente que os usuários que pertencem ao grupo Aprovadores Autorizados preencham o campo Aprovado por
- Desmarque o campo Aprovado por quando o Estado for movido para Recortar
- Exigir que os Critérios de Aceitação sejam preenchidos quando o Estado for movido para Ativo
Definições de função
Para implementar as restrições acima, o administrador do processo adiciona um campo de identidade Aprovado por personalizado, um grupo de segurança Aprovadores Autorizados e as onze regras a seguir.
Nome da regra
Condição
Ações
Estado proposto
Quando A work item state moved from Proposed
Então Restrict the state transition to Design
E Restrict the state transition to Approved
E Restrict the state transition to Active
E Restrict the state transition to In Review
E Restrict the state transition to Closed
Estado de pesquisa
Quando A work item state moved from Research
Então Restrict the state transition to Proposed
E Restrict the state transition to Approved
E Restrict the state transition to Active
E Restrict the state transition to In Review
E Restrict the state transition to Closed
Estado de design
Quando A work item state moved from Design
Então Restrict the state transition to Proposed
E Restrict the state transition to Research
E Restrict the state transition to Active
E Restrict the state transition to In Review
E Restrict the state transition to Closed
Estado aprovado
Quando A work item state moved from Approved
Então Restrict the state transition to Proposed
E Restrict the state transition to Research
E Restrict the state transition to Design
E Restrict the state transition to In Review
E Restrict the state transition to Closed
Estado Ativo
Quando A work item state moved from Active
Então Restrict the state transition to Proposed
E Restrict the state transition to Research
E Restrict the state transition to Design
E Restrict the state transition to Approved
E Restrict the state transition to Closed
Em Estado de revisão
Quando A work item state moved from In Review
Então Restrict the state transition to Proposed
E Restrict the state transition to Research
E Restrict the state transition to Design
E Restrict the state transition to Approved
Estado fechado
Quando A work item state moved from Closed
Então Restrict the state transition to Proposed
E Restrict the state transition to Cut
Estado de corte
Quando A work item state moved from Cut
Então Restrict the state transition to Research
E Restrict the state transition to Design
E Restrict the state transition to Approved
E Restrict the state transition to Active
E Restrict the state transition to In Review
E Restrict the state transition to Closed
Campos obrigatórios de estado aprovado
Quando A work item changes from Approved to Active
Então Make required Acceptance Criteria
E Make required Approved By
Aprovadores autorizados
Quando Current user is not a member of Authorized Approvers
Então Make read-only Approved By
Limpar o campo Aprovado por
Quando A work item state changes to Cut
Então Clear the value of Approved By
Verificar restrições de transição de estado
Depois que as regras forem definidas para o processo e o projeto atualizado com o processo, atualize o navegador e marcar as operações por meio do formulário do item de trabalho e do navegador Kanban.
Para as regras definidas na tabela anterior, você deverá ver os seguintes menus suspensos estado. Abra o quadro Kanban e marcar a capacidade de mover de um Estado para outro.
Proposto | Pesquisa | Projetar | Aprovado |
---|---|---|---|
Ativo | Em Revisão | Fechadas | Recortar |
Restringir a transição de estado com base na associação de usuário ou grupo
Ao especificar uma das duas condições com base na associação de usuário ou grupo, Current user is member of group ...
ou Current user is not member of group ...
, você pode especificar apenas uma condição. Além disso, se especificar a ação Restrict the transition to state...
, você só poderá especificar uma ação.
Observação
Os itens de trabalho estão sujeitos a regras aplicadas a eles. As regras condicionais baseadas na associação de usuários ou grupos são armazenadas em cache para o navegador da Web. Se você se achar restrito a atualizar um item de trabalho, talvez tenha encontrado uma dessas regras. Se você acredita que encontrou um problema que não se aplica a você, confira Problemas de cache do IndexDB de formulário de item de trabalho.
Automatizar transições de estado de itens de trabalho pai
Para automatizar as transições de estado dos itens de trabalho pai com base nas atribuições de Estado feitas aos itens de trabalho filho, você pode adicionar um gancho da Web e usar o código e a configuração fornecidos no projeto GitHub Automatizar Transições de Estado .
Observação
O projeto GitHub Automatizar Transições de Estado não é um recurso compatível com Azure Boards e, portanto, não tem suporte da equipe de produtos. Para perguntas, sugestões ou problemas que você tem ao usar essas extensões, gere-as na página de projeto do GitHub.
Automatizar a reatribuição com base na alteração de estado
O tipo de item de trabalho de bug de processo Agile anteriormente tinha uma regra que reatribuia o bug à pessoa que o criou. Essa regra foi removida do processo do sistema padrão. Você pode restabelecer a regra ou adicionar uma regra semelhante a outros tipos de item de trabalho usando a seguinte condição e ação:
QuandoA work item state changes to
Resolvidoem seguidaCopy the value from
, criado porparaatribuído a.
Artigos relacionados
Observação
Você pode examinar as alterações feitas em um processo herdado por meio do log de auditoria. Para saber mais, confira Acessar, exportar e filtrar logs de auditoria.
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