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, 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 a estados de fluxo de trabalho oferece suporte aos seguintes cenários:

• Apoiar 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 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
• Automatize o fechamento de itens de trabalho pai

Analise este artigo para entender como definir regras que se aplicam quando você altera um estado de fluxo de trabalho.

• Compreender os tipos de regras de fluxo de trabalho
• Estado do fluxo de trabalho e limites de regras 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 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

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 apoiam a restrição das transições de estado. Esses dois grupos permitem 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.

---

Condição

Ações apoiadas

---

Definir valor de campo ou tornar somente leitura/obrigatório com base no estado

---

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

---

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 suave, recomendamos a criação de 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.

Estado do fluxo de trabalho e limites de regra

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 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

Definir uma regra

Antes de definir uma regra com base nos estados do fluxo de trabalho, certifique-se de definir primeiro os seguintes elementos:

• Os estados do fluxo de trabalho desejados, 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 sua regra exigir a especificação de um grupo de segurança para conceder ou restringir alterações com base na associação de usuário ou grupo, defina esse grupo de segurança conforme descrito em Adicionar ou remover usuários ou grupos, gerenciar 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 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 estão em uso e apenas um único campo personalizado, Aprovado por, e o grupo de segurança, Grupo de Líderes de Equipe, são adicionados.

Estados padrão do fluxo de trabalho

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 os usuários que não pertencem ao Grupo de Líderes de Equipe a preencher o campo Aprovado por
• Limpar o campo Aprovado por quando o Estado passar 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 liberado quando novo

Quando A work item state changes to New

Então Clear the value of Approved By

Aprovado por limpo 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 requerido

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.

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

Sem quaisquer restrições, os usuários podem se mover de um Estado para qualquer outro, 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 para frente e para trás no tipo de item de trabalho User Story.

• Proposta só pode passar para Pesquisa e Corte
• A pesquisa só pode passar para Design e Corte
• O design só pode passar para Pesquisa, Aprovado e Recortado
• Aprovado só pode passar para Design, Ativo e Recortado
• Ativo só pode mover para Em revisão
• Em Revisão só pode mover para Ativo (Trabalho adicional encontrado), Fechado ou Recortado
• Fechado pode mover para Pesquisa, Design, Ativo, Em revisão (Permite casos em que o usuário fechou o item de trabalho por engano)
• Corte só pode passar para Proposto.

Observação

Ao restringir transições de estado, considere os casos em que um usuário move um estado por engano. Você quer que os usuários possam se recuperar normalmente.

Além disso, o grupo empresarial deseja aplicar 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 que pertencem ao grupo Aprovadores Autorizados preencham o campo Aprovado por
• Limpar o campo Aprovado por quando o Estado passar para Cortar
• Exigir que os Critérios de Aceitação sejam preenchidos quando o Estado passar 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 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 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 do 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

Campo Limpar 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 estiverem definidas para o processo e o projeto atualizado com o processo, atualize seu navegador e verifique as operações através do formulário de item de trabalho e do navegador.

Para as regras definidas na tabela anterior, você deve ver os seguintes menus suspensos Estado. Abra o quadro e verifique a capacidade de se mover de um Estado para outro.

Proposto	Pesquisar	Projetar	Aprovado
Com atividade	Em revisão	Fechado	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ê 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 de itens de trabalho pai com base nas atribuições de estado feitas a seus 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 com suporte do Azure Boards e, portanto, não é suportado pela equipe do produto. Para dúvidas, sugestões ou problemas que você tenha ao usar essas extensões, levante-as na página do projeto do GitHub.

Automatizar a reatribuição com base na alteração de estado

O tipo de item de trabalho de bug do processo Agile 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:

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

Artigos relacionados

Observação

Revise as alterações feitas em um processo herdado por meio do log de auditoria. Para obter mais informações, consulte Acessar logs de auditoria de filtro.

• Personalizar um fluxo de trabalho
• Adicionar uma regra personalizada
• Cache de formulário de item de trabalho