Compartilhar via


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 os estados do fluxo de trabalho para um tipo de item de trabalho, defina regras que se aplicam com base na alteração do estado do fluxo de trabalho. A adição de regras aos estados do fluxo de trabalho dá suporte aos seguintes cenários:

  • Ofereça suporte a um processo de aprovação
  • Impedir que usuários não autorizados definam um estado inválido
  • Tornar um campo obrigatório ou somente leitura ou outro valor com base nas 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, suportando os requisitos de auditoria
  • Automatizar o fechamento de itens de trabalho pai
  • Ofereça suporte a um processo de aprovação
  • Impedir que usuários não autorizados definam um estado inválido
  • Tornar um campo obrigatório ou somente leitura ou outro valor com base nas alterações de estado
  • Restringir a transição de um estado para outro
  • Automatizar o fechamento de itens de trabalho pai
  • Ofereça suporte a um processo de aprovação
  • Tornar um campo obrigatório ou somente leitura ou outro valor com base nas alterações de estado
  • Automatizar o fechamento de itens de trabalho pai

Importante

O modelo de processo de herança está disponível para projetos configurados para dar suporte a ele. Se você estiver usando uma coleção mais antiga, verifique a compatibilidade do modelo de processo. 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 obter mais informações, consulte Escolher o modelo de processo para sua coleção de projetos.

Pré-requisitos

Para aplicar regras a estados de fluxo de trabalho no Azure DevOps, você precisa de permissões e níveis de acesso específicos:

  • Permissões:

    • Seja um administrador de projeto para gerenciar grupos de segurança e permissões no nível do projeto, o que inclui a configuração de regras para estados de fluxo de trabalho.
    • Ter permissão de Acompanhamento de Item de Trabalho, que permite gerenciar a área de acompanhamento de trabalho, que pode ser concedida a membros do grupo Administradores de Projeto ou por meio de permissões específicas.
  • Níveis de acesso:

    • Ter acesso básico , que normalmente é suficiente para a maioria dos usuários que precisam gerenciar itens de trabalho e aplicar regras a estados de fluxo de trabalho.

Entender as regras de fluxo de trabalho

A tabela a seguir descreve os três grupos de regras de fluxo de trabalho que você pode definir:

  1. Ações padrão:

    • Aplicar quando um item de trabalho é criado, em um estado selecionado ou movido de um estado para outro.
    • As ações incluem definir o valor de um campo, tornar um campo somente leitura ou tornar um campo obrigatório.
    • Você pode especificar uma ou duas condições e várias ações.
  2. Restringindo transições de estado (grupo 1):

    • Especifique uma condição que indica o estado do qual um item de trabalho foi movido.
    • Defina ações para restringir as transições desse estado para outros estados.
  3. Restringindo transições de estado (grupo 2):

    • Semelhante ao primeiro grupo, especifique uma condição indicando o estado do qual um item de trabalho foi movido.
    • Defina ações para restringir as transições desse estado para outros estados.

A tabela a seguir descreve os dois grupos de regras de fluxo de trabalho que você pode definir:

  1. Ações padrão:

    • Aplicar quando um item de trabalho é criado, em um estado selecionado ou movido de um estado para outro.
    • As ações incluem definir o valor de um campo, tornar um campo somente leitura ou tornar um campo obrigatório.
    • Você pode especificar uma ou duas condições e várias ações.
  2. Restringindo transições de estado:

    • Especifique uma condição que indica o estado do qual um item de trabalho foi movido.
    • Defina uma ou mais ações para restringir as transições 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 do Azure DevOps Server 2020 Atualização 1 RC1, Quadros.

As condições e ações do 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


Defina o valor do campo ou torne somente leitura/obrigatório com base no Estado

Condições, o item de trabalho é criado

Ações, item de trabalho é criado


Restringir uma transição com base no Estado

Condição, item de trabalho é movido

Ações, restringir uma transação com base no Estado.


Ocultar campo ou tornar o campo somente leitura ou obrigatório com base no estado e na associação de usuário ou grupo

Condição, associação ao grupo de usuários

Ações, restringir uma transação com base no Estado e na associação.


Com base em uma associação de usuário ou grupo, defina um atributo de campo ou restrinja uma transição de Estado

Condição, associação ao grupo de usuários

Ações, restringir uma transação com base no Estado e na associação.


Observação

Quando você personaliza um processo herdado, todos os projetos que usam esse processo refletem automaticamente as personalizações. Para garantir uma transição tranquila, recomendamos criar um processo de teste e um projeto, que permite testar suas personalizações antes de implementá-las em toda a organização. Para obter mais informações, consulte Criar e gerenciar processos herdados.

Entender o estado do fluxo de trabalho e os limites da regra

As regras de fluxo de trabalho são aplicadas quando você adiciona ou modifica 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 ou Quadro de Tarefas, mover item de trabalho para 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

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, siga estas diretrizes para minimizar problemas de desempenho:

  • Limitar o número de regras para um WIT: embora você possa criar várias regras para um WIT (tipo de item de trabalho), mais regras podem afetar negativamente o desempenho quando os usuários adicionam ou modificam itens de trabalho. O sistema valida todas as regras associadas aos campos para o tipo de item de trabalho quando os usuários salvam itens de trabalho. Em alguns casos, a expressão de validação de regra pode se tornar muito complexa para o SQL avaliar.
  • Limite o número de tipos de item de trabalho personalizados: reduzir o número de tipos de item de trabalho personalizados pode ajudar a manter o desempenho ideal.

Definir uma regra

Antes de definir uma regra com base nos estados do fluxo de trabalho, verifique se os seguintes elementos estão em vigor:

Para obter mais informações sobre como definir regras, consulte Adicionar uma regra personalizada.

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 querem 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 são usados, com a adição de um campo personalizado, Aprovado por, e um grupo de segurança, Grupo de Líderes de Equipe.

Estados de fluxo de trabalho padrão

Processo Agile, História do Usuário, estado padrão do fluxo de trabalho

Requisitos da regra

Para garantir a aprovação antes do trabalho ativo, defina as seguintes regras:

  • Exigir que o campo Aprovado por seja preenchido quando o Estado passar de Novo para Ativo
  • Impedir que os usuários que não estão no grupo de líderes de equipe preencham 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 se traduzem 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 exigido

Quando A work item state changes from New to Active

Então Make required Approved By


Restringir transições de estado

Ao especificar a condição, A work item state moved from ..., você pode especificar somente 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

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, são usados os estados Proposto, Em Revisão e Corte . Além disso, mais três estados são definidos: Investigar, Projetar e Aprovado. Esses estados devem seguir a sequência mostrada na imagem a seguir.

História do usuário, estados de fluxo de trabalho

Sem quaisquer restrições, os usuários podem se mover de um estado para qualquer outro estado, tanto para frente quanto para trás dentro da sequência.

Requisitos da regra

Para dar suporte a um fluxo de trabalho mais controlado, o grupo de negócios decidiu instituir regras que dão suporte às seguintes transições de estado de avanço e inversão no tipo de item de trabalho História do Usuário.

Estado Regra de transição
Proposto Só pode ir para Pesquisa e Corte
Pesquisa Só pode ser movido para Design e Corte
Criar Só pode ser movido para Pesquisa, Aprovado e Cortado
Aprovada Só pode ser movido para Design, Ativo e Recortar
Ativa Só pode mover para Em revisão
Em Revisão Só pode ser movido para Ativo (mais trabalho encontrado), Fechado ou Cortado
Fechado Pode mover para Pesquisa, Design, Ativo, Em Revisão (Permite casos em que o usuário fechou o item de trabalho por engano)
Recortar só pode mover para Proposto

Observação

Ao restringir as transições de estado, considere os casos em que um usuário pode mover um estado por engano. Certifique-se de que os usuários possam se recuperar normalmente.

Além disso, o grupo de negócios deseja aplicar as seguintes regras para campos obrigatórios:

  • Exigir que o campo Aprovado por seja preenchido quando o estado passar de Aprovado para Ativo.
  • Permitir que apenas os usuários do grupo Aprovadores Autorizados preencham o campo Aprovado por .
  • Desmarque o campo Aprovado por quando o estado for movido para Recortar.
  • Exigir que o campo Critérios de aceitação seja preenchido quando o estado for movido para Ativo.

Definições de função

Para implementar as restrições mencionadas anteriormente, o administrador do processo adiciona um campo de identidade personalizado Aprovado por , um grupo de segurança Aprovadores Autorizados e as 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 da 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 do projeto

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

No 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

Desmarque 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 de definir as regras para o processo e atualizar o projeto, atualize seu navegador. Verifique as operações por meio do formulário de item de trabalho e do navegador.

Para as regras definidas na tabela anterior, verifique os menus suspensos Estado. Abra o quadro e certifique-se de que você pode passar de um estado para outro.

Proposto Pesquisar Projetar Aprovado
Menu proposto Menu de pesquisa Menu Design Menu aprovado
Com atividade Em revisão Fechado Recortar
Menu ativo No menu Revisão Menu fechado Menu de corte

Restringir a transição de estado com base na associação de usuário ou grupo

Quando você especifica 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ê só pode especificar uma condição. Além disso, se você especificar a ação Restrict the transition to state..., poderá especificar apenas 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ê perceber que está 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 transições de estado para itens de trabalho pai baseados nas atribuições de estado de seus itens de trabalho filho, consulte Automatizar transições de estado de item de trabalho.

Automatize a reatribuição com base na mudança de estado

O tipo de item de trabalho de bug do processo Agile anteriormente tinha uma regra que reatribuía o bug ao seu criador. Removemos essa regra do processo padrão do sistema. 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:

Quando A work item state changes to resolvido, em seguida, Copy the value from criado por para atribuído a.