Aplicar regras aos estados do fluxo de trabalho (processo de herança)
Serviços de DevOps do Azure | 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 aos estados do 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
- 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
- Automatize o fechamento de itens de trabalho pai
- Apoiar um processo de aprovação
- Tornar um campo obrigatório ou somente leitura ou outro valor com base em alterações de estado
- Automatize o fechamento de itens de trabalho pai
Consulte este artigo para entender como definir regras que se aplicam quando você altera o estado de um 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
- Automatize transições de estado de itens de trabalho pai
- 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
- Automatize transições de estado de itens de trabalho pai
- 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
- Automatize transições de estado de itens de trabalho pai
Importante
O modelo de processo de herança está disponível para projetos configurados para suportá-lo. 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 controle de trabalho. Para obter mais informações, consulte Escolher o modelo de processo para sua coleção de projetos.
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. Neste grupo, você pode especificar uma ou duas condições e várias ações.
O segundo e terceiro grupos apoiam a restrição das transições de Estado. Esses dois grupos permitem especificar uma e apenas uma condição que indica 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. Neste grupo, você pode especificar uma ou duas condições e várias ações.
O segundo grupo apoia a restrição de transições de estado. Neste segundo grupo, você pode especificar uma e apenas uma condição que indica 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.
Nota
Alguns recursos exigem a instalação da atualização do Azure DevOps Server 2020.1. Para obter mais informações, consulte Azure DevOps Server 2020 Update 1 RC1 Release Notes, Boards.
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.
Condition
Ações apoiadas
Definir valor de campo ou tornar somente leitura/obrigatório com base no Estado
Restringir uma transiçã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
Com base na associação de usuário ou grupo, defina um atributo de campo ou restrinja uma transição de Estado
Nota
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 e projeto de teste, 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 regras
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 definidas 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 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:
- O fluxo de trabalho indica 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 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á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 informações básicas sobre a 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 de equipe antes do trabalho ativo
Neste exemplo, as equipes de desenvolvimento querem garantir que nenhuma história de usuário seja trabalhada até ser 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 de fluxo de trabalho padrão
Requisitos da 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
- Limpe o campo Aprovado por quando o Estado for movido para Novo ou Removido
Definições de regras
Os requisitos de regra se traduzem nas quatro definições de regra a seguir.
Nome da regra
Condition
Ações
Aprovado por limpo quando Novo
Quando A work item state changes to New
Em seguida, Clear the value of Approved By
Aprovado por limpo quando removido
Quando A work item state changes to Removed
Em seguida, Clear the value of Approved By
Aprovado por somente 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 ...
, você pode especificar apenas essa condição. Você pode especificar até 10 ações.
Nota
Esse recurso requer a atualização do 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 User Story. Os estados herdados Novo, Resolvido e Removido estão ocultos. Em vez disso, são usados Estados propostos, em revisão e cortados. Além disso, três Estados adicionais são definidos: Investigar, Projetar e Aprovado. Esses estados devem seguir a sequência como mostrado na imagem a seguir.
Sem quaisquer restrições, os utilizadores podem deslocar-se de um Estado para qualquer outro, tanto para a frente como 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 suportariam as 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 investigação só pode passar para o Design and Cut
- O design só pode passar para Pesquisa, Aprovado e Corte
- Aprovado só pode ser movido para Design, Ativo e Corte
- Ativo só pode ser movido para Em revisão
- Em Revisão só pode ser movido 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.
Nota
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 a cortar
- Exigir que os Critérios de Aceitação sejam preenchidos quando o Estado passar para Ativo
Definições de regras
Para implementar as restrições acima, o administrador do processo adiciona um campo personalizado de identidade Aprovado por, um grupo de segurança Aprovadores autorizados e as onze regras a seguir.
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 ainda Restrict the state transition to Approved
e ainda Restrict the state transition to Active
e ainda Restrict the state transition to In Review
e ainda 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 ainda Restrict the state transition to Approved
e ainda Restrict the state transition to Active
e ainda Restrict the state transition to In Review
e ainda Restrict the state transition to Closed
Estado do design
Quando A work item state moved from Design
Em seguida, Restrict the state transition to Proposed
e ainda Restrict the state transition to Research
e ainda Restrict the state transition to Active
e ainda Restrict the state transition to In Review
e ainda 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 ainda Restrict the state transition to Research
e ainda Restrict the state transition to Design
e ainda Restrict the state transition to In Review
e ainda 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 ainda Restrict the state transition to Research
e ainda Restrict the state transition to Design
e ainda Restrict the state transition to Approved
e ainda Restrict the state transition to Closed
Em estado de revisão
Quando A work item state moved from In Review
Em seguida, Restrict the state transition to Proposed
e ainda Restrict the state transition to Research
e ainda Restrict the state transition to Design
e ainda 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 ainda Restrict the state transition to Cut
Estado de corte
Quando A work item state moved from Cut
Em seguida, Restrict the state transition to Research
e ainda Restrict the state transition to Design
e ainda Restrict the state transition to Approved
e ainda Restrict the state transition to Active
e ainda Restrict the state transition to In Review
e ainda Restrict the state transition to Closed
Campos obrigatórios do estado aprovado
Quando A work item changes from Approved to Active
Em seguida, Make required Acceptance Criteria
e ainda 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 restrições de transição de estado
Uma vez que as regras são 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ê verá os seguintes menus suspensos Estado. Abra o quadro e verifique a capacidade de se deslocar de um Estado para outro.
Proposta | Investigação | Desenho | Aprovado |
---|---|---|---|
![]() |
![]() |
![]() |
![]() |
Activo | Em revisão | Fechadas | Corte |
![]() |
![]() |
![]() |
![]() |
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.
Nota
Os itens de trabalho estão sujeitos a regras aplicadas a eles. As regras condicionais baseadas na associação de usuário ou grupo são armazenadas em cache para seu navegador da Web. Se você estiver restrito a atualizar um item de trabalho, talvez tenha encontrado uma dessas regras. Se você acredita ter encontrado um problema que não se aplica a você, consulte Problemas de cache do IndexDB do formulário de item de trabalho.
Automatize transições de estado de itens de trabalho pai
Para automatizar as transições de Estado de 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 Automatizar Transições de Estado do GitHub.
Nota
O projeto Automatizar Transições de Estado do GitHub 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ê tem ao usar essas extensões, levante-as na página do projeto GitHub.
Automatize a reatribuição com base na alteração de estado
O tipo de item de trabalho de bug do processo Agile anteriormente tinha uma regra que reatribuía o bug à pessoa que o criou. Esta regra foi removida 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.
Artigos relacionados
Nota
Revise as alterações feitas em um processo herdado por meio do log de auditoria. Para obter mais informações, consulte Acesso, exportação e filtro de logs de auditoria.
Comentários
https://aka.ms/ContentUserFeedback.
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja:Submeter e ver comentários