Aplicar regras a estados de fluxo de trabalho (Processo de herança)

Serviços do Azure DevOps | 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, poderá querer definir uma ou mais regras que são aplicadas consoante a alteração do estado do fluxo de trabalho. A adição de regras aos estados de fluxo de trabalho suporta os seguintes cenários:

• Suportar um processo de aprovação
• Impedir que utilizadores não autorizados definam um estado inválido
• Tornar um campo obrigatório, só de 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 utilizadores ou grupos específicos
• Manter um processo de fluxo de trabalho controlado para suportar os requisitos de auditoria
• Automatizar o encerramento de itens de trabalho principais

Veja este artigo para compreender como definir regras que se aplicam quando altera um estado de fluxo de trabalho.

• Compreender os tipos de regras de fluxo de trabalho
• Limites de regras e estado do fluxo de trabalho e melhores práticas
• Definir um valor de campo ou tornar um campo só de leitura ou necessário com base na seleção de Estado
• Restringir transições de estado
• Restringir ou permitir transições de Estado para utilizadores ou grupos específicos
• Automatizar transições de estado de itens de trabalho principais

Importante

Este artigo aplica-se aos Serviços do Azure DevOps e Azure DevOps Server 2019 e versões posteriores. Para personalizar qualquer projeto definido numa coleção para o TFS 2018 ou anterior, veja Modelo de processo XML no local.

Regras de fluxo de trabalho

A tabela seguinte indica os três grupos de regras de fluxo de trabalho que pode definir. O primeiro grupo aplica ações padrão quando um item de trabalho é criado, num estado selecionado ou é movido de um estado para outro. Estas ações padrão definem o valor de um campo ou tornam um campo só de leitura ou obrigatório. Neste grupo, pode especificar uma ou duas condições e várias ações.

O segundo e terceiro grupos suportam a restrição de transições de estado. Estes dois grupos permitem-lhe especificar uma e apenas uma condição que indica o estado para o qual um item de trabalho foi movido. Em seguida, pode especificar uma ou mais ações para restringir a transição desse estado para outros estados.

---

Condition

Ações Suportadas

---

Definir o valor do campo ou tornar só de leitura/obrigatório com base no Estado

---

Com base na associação de utilizadores ou grupos, defina um atributo de campo ou restrinja uma transição de Estado

---

Nota

À medida que personaliza um processo herdado, todos os projetos que utilizam esse processo são atualizados automaticamente para refletir as personalizações. Por este motivo, recomendamos que crie um processo de teste e teste o projeto quando tiver várias personalizações a efetuar para testar as personalizações antes de as implementar na sua organização. Para saber mais, veja Criar e gerir processos herdados.

Limites de regras e estado do fluxo de trabalho

A seguinte tabela resume os limites de estado e de regra do fluxo de trabalho para o processo de Herança.

Objeto	Limite de herança
Tipos de itens de trabalho definidos para um processo	64
Estados de 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 considere a seguinte documentação de orientação para minimizar os problemas de desempenho.

• Minimize o número de regras que define para um WIT. Embora possa criar várias regras para um WIT, as regras de adição podem afetar negativamente o desempenho quando um utilizador adiciona e modifica itens de trabalho. Quando os utilizadores guardam itens de trabalho, o sistema valida todas as regras associadas aos campos do respetivo tipo de item de trabalho. Em determinadas condições, a expressão de validação de regras é demasiado complexa para o SQL avaliar.
• Minimize o número de WITs personalizados que define.

As regras de fluxo de trabalho são aplicadas ao adicionar ou modificar itens de trabalho através de qualquer uma das seguintes interfaces:

• Portal Web: formulário de item de trabalho, atualizações em massa, atualizações na vista de consulta
• Portal Web: quadro Kanban 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 ficheiro 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 que define primeiro os seguintes elementos:

• O fluxo de trabalho indica que pretende, conforme descrito em Personalizar um fluxo de trabalho
• Se a regra exigir especificação de um campo personalizado, adicione esse campo ao tipo de item de trabalho, conforme descrito em Adicionar e gerir campos
• Se a regra exigir especificação de um grupo de segurança para conceder ou restringir alterações com base na associação de utilizadores ou grupos, defina esse grupo de segurança conforme descrito em Adicionar ou remover utilizadores ou grupos, faça a gestão de grupos de segurança.

Para obter as noções básicas da definição de regras, veja Adicionar uma regra personalizada. Tem de cumprir os pré-requisitos definidos nesse artigo.

Definir o valor do campo ou tornar o campo só de leitura ou obrigatório

Com o primeiro agrupamento de regras, pode especificar uma ou duas condições e até 10 ações por regra.

Exemplo de garantir a aprovação de oportunidades potenciais da equipa antes do trabalho ativo

Neste exemplo, as equipas de desenvolvimento querem garantir que nenhum User Story é trabalhado até ser aprovado por um líder de equipa. Os estados de fluxo de trabalho predefinidos estão a ser utilizados e são adicionados apenas um único campo personalizado, Aprovado Por, e o grupo de segurança Grupo de Líderes de Equipa.

Estados de fluxo de trabalho predefinidos

Requisitos de regras

Para garantir a aprovação antes do trabalho ativo, têm de ser definidas as seguintes regras:

• Exigir que o campo Aprovado Por seja preenchido quando o Estado mudar de Novo para Ativo
• Restringir os utilizadores que não pertencem ao Grupo de Oportunidades Potenciais de Equipa para preencher o campo Aprovado Por
• Limpar o campo Aprovado Por quando o Estado mudar para Novo ou Removido

Definições de regras

Os requisitos de regras traduzem-se nas seguintes quatro definições de regra.

   

---

Nome da regra

Condition

Ações

---

Aprovado Por desmarcado quando Novo

Quando A work item state changes to New

Em seguida, Clear the value of Approved By

Aprovado Por desmarcado quando Removido

Quando A work item state changes to Removed

Em seguida, Clear the value of Approved By

Aprovado Por Só de Leitura

Quando Current user is not member of group Team Leads Group

Em seguida, Make read-only Approved By

Aprovado Por obrigatório

Quando A work item state changes from New to Active

Em seguida, Make required Approved By

---

Restringir transições de estado

Ao especificar a condição, A work item state moved from ..., só pode especificar essa condição. Pode especificar até 10 ações.

Exemplo de restrição de transições de estado e estado Aprovado

De acordo com a terminologia utilizada por um grupo empresarial, os seguintes estados de fluxo de trabalho são definidos para o User Story. Os estados herdados Novo, Resolvido e Removido estão ocultos. Em vez disso, são utilizados Os Estados Propostos, Em Revisão e Cortados são utilizados. Além disso, são definidos três Estados adicionais: Investigar, Estruturar e Aprovados. Estes Estados devem seguir a sequência conforme mostrado na imagem seguinte.

Sem quaisquer restrições, os utilizadores podem passar de um Estado para qualquer outro Estado, tanto para a frente como para trás na sequência.

Requisitos de regras

Para suportar um fluxo de trabalho mais controlado, o grupo empresarial decidiu instituir regras que suportariam as seguintes transições de estado reencaminhamento e inverso no tipo de item de trabalho História do Utilizador.

• Proposta só pode mudar para Pesquisa e Corte
• A pesquisa só pode mudar para Design e Cortar
• O design só pode mudar para Pesquisa, Aprovado e Cortar
• Aprovado só pode mover para Estrutura, Ativo e Cortar
• O ativo só pode ser movido para Em Revisão
• Em Rever só pode mover para Ativo (Trabalho adicional encontrado), Fechado ou Cortado
• Fechado pode mover-se para Pesquisa, Estrutura, Ativo, Em Revisão (Permite casos em que o utilizador fechou o item de trabalho por erro)
• Cortar só pode mover-se para Proposto.

Nota

Ao restringir as transições de estado, considere os casos em que um utilizador move um estado por engano. Quer que os utilizadores consigam recuperar corretamente.

Além disso, o grupo empresarial quer aplicar regras para os campos necessários:

• Exigir que o campo Aprovado Por seja preenchido quando o Estado passar de Aprovado para Ativo
• Permitir apenas que os utilizadores que pertencem ao grupo Aprovadores Autorizados preencham o campo Aprovado Por
• Desmarque o campo Aprovado Por quando o Estado mudar para Cortar
• Exigir que os Critérios de Aceitação estejam preenchidos quando o Estado mudar para Ativo

Definições de regras

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

   

---

Nome da regra

Condition

Ações

---

Estado proposto

Quando A work item state moved from Proposed

Em seguida, 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 investigação

Quando A work item state moved from Research

Em seguida, 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 da estrutura

Quando A work item state moved from Design

Em seguida, 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

Em seguida, 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

Em seguida, 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 Rever

Quando A work item state moved from In Review

Em seguida, 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

Em seguida, Restrict the state transition to Proposed
E Restrict the state transition to Cut

Cortar estado

Quando A work item state moved from Cut

Em seguida, 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 necessários para o estado aprovado

Quando A work item changes from Approved to Active

Em seguida, Make required Acceptance Criteria
E Make required Approved By

Aprovadores Autorizados

Quando Current user is not a member of Authorized Approvers

Em seguida, Make read-only Approved By

Limpar campo Aprovado Por

Quando A work item state changes to Cut

Em seguida, Clear the value of Approved By

---

Verificar as restrições de transição de estado

Assim que as regras estiverem definidas para o processo e o projeto for atualizado com o processo, atualize o browser e verifique as operações através do formulário do item de trabalho e do browser Kanban.

Para as regras definidas na tabela anterior, deverá ver os seguintes menus pendentes de Estado. Abra o quadro Kanban e verifique a capacidade de passar de um Estado para outro.

Proposto	Investigação	Design	Aprovado
Ativo	Em Rever	Fechado	Cortar

Restringir a transição de estado com base na associação de utilizadores ou grupos

Ao especificar uma das duas condições com base na associação de utilizadores ou grupos, Current user is member of group ... ou Current user is not member of group ..., só pode especificar uma condição. Além disso, se especificar a ação Restrict the transition to state..., só pode especificar uma ação.

Nota

Os itens de trabalho estão sujeitos a regras aplicadas aos mesmos. As regras condicionais baseadas na associação de utilizadores ou grupos são colocadas em cache para o browser. Se estiver restrito a atualizar um item de trabalho, poderá ter encontrado uma destas regras. Se acredita ter encontrado um problema que não se aplica a si, veja Problemas de colocação em cache do Formulário de item de trabalho IndexDB.

Automatizar transições de estado de itens de trabalho principais

Para automatizar as transições de Estado dos itens de trabalho principais com base nas atribuições de Estado efetuadas aos respetivos itens de trabalho subordinados, pode adicionar um web hook e utilizar o código e a configuração fornecidos no projeto GitHub de Transições de Estado Automatizadas .

Nota

O projeto Do GitHub de Transições de Estado Automatização não é uma funcionalidade suportada do Azure Boards e, por conseguinte, não é suportado pela equipa de produtos. Para perguntas, sugestões ou problemas que tem ao utilizar estas extensões, levante-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 processo ágil tinha anteriormente uma regra que reatribuia o erro à pessoa que o criou. Esta regra foi removida do processo de sistema predefinido. Pode restabelecer a regra ou adicionar uma regra semelhante a outros tipos de itens de trabalho com a seguinte condição e ação:

QuandoA work item state changes toResolvido, em seguida,Copy the value from criado porparaatribuído a.

Artigos relacionados

Nota

Pode rever as alterações efetuadas a um processo herdado através do registo de auditoria. Para saber mais, veja Aceder, exportar e filtrar registos de auditoria.

• Personalizar um fluxo de trabalho
• Adicionar uma regra personalizada
• Colocação em cache de formulários de item de trabalho