Compartilhar via


Automatizar atribuições de campo com base em estado, transição ou motivo

Talvez você queira fazer automaticamente a transição de itens de trabalho de um estado para outro estado com base em um evento que ocorre em outro lugar no Visual Studio Application Lifecycle Management (ALM) ou um evento que ocorre fora do Visual Studio ALM. Por exemplo, convém automatizar a transição de um bug de um estado para outro com base no que ocorre em uma ferramenta de controle de chamada. O modelo de tipo de item de trabalho e a API de controle Item de trabalho são estendidos para oferecer suporte a transição automática de itens de trabalho por outros sistemas.

Se você tiver o código que altera o estado de um item de trabalho, pode generalizar esse código, associando a ação a transição de estado apropriado usando a ACTION elemento. Você pode passar o valor da ação para o [WorkItem.GetNextState] método para obter o estado de pós-ação desse item de trabalho. A caixa de diálogo de check-in de controle de versão usa esse método para resolver bugs e tarefas que estão associadas com o check-in de fechar.

O ACTION é um elemento filho opcional de ACTIONS.

Dica

A API de rastreamento de Item de trabalho é parte do Visual Studio ALM SDK, conforme descrito na seguinte página no site da Microsoft: Estendendo o Team Foundation.

Por exemplo, uma ferramenta é predefinida para transição automaticamente um item de trabalho "Resolvido" depois que o usuário faz uma alteração. No entanto, como um provedor de integração, você não souber qual estado autor do tipo de item de trabalho foi declarado como "Resolvido". O autor pode significar resolvido, fechado, concluído, pronto para teste, incluir na compilação e assim por diante. Uma opção seria exigir todos os autores de tipo de item de trabalho incluir um estado explicitamente chamado "Resolvido".

Essa solução é restritiva demais. Também é ruim de uma perspectiva internacional porque ele não permite a localização de estados. Em vez disso, integradores de sistema podem declarar uma ação, como "Check-in" ou "Complete" que induz a uma transição automática para itens de trabalho. Autor do tipo de item de trabalho, em seguida, poderia declarar essa ação na transição apropriada.

Neste tópico

  • Sintaxe do elemento de ação

  • Etapas necessárias para oferecer suporte a automação

  • Associando a uma ação de uma transição de estado

  • Detalhes da ação de transição

  • Verificação de erros de transição automática

Sintaxe do elemento de ação

A sintaxe a seguir é usada para o ACTION elemento. O atributo de valor Especifica o nome da ação e é necessário. Você deve seguir as mesmas convenções de nomenclatura para ações como nomes de campos de referência. Por exemplo, Controle de versão do Team Foundation usa Checkin para identificar a transição é apropriada para itens de trabalho que estão associados com o check-in. Para obter mais informações, consulte As convenções de nomenclatura para objetos de rastreamento de Item de trabalho.

<ACTION value="NameOfAction" />

minOccurs = "0"

maxOccurs = "ilimitado"

Etapas necessárias para oferecer suporte a automação

Para integrar a uma ferramenta Work Item Tracking, a ferramenta deve executar as seguintes etapas:

  1. Determine os estados de item de trabalho deve ser transferido para quando a ação é executada.

  2. Defina o item de trabalho para o estado "para".

    A API de rastreamento de Item de trabalho fornece métodos para executar essas etapas. A API de rastreamento de Item de trabalho é parte do Visual Studio ALM SDK. Para obter mais informações, consulte a seguinte página no site da Microsoft: SDK do Team Foundation Server.

    Dica

    A ação de transação que causou uma transição de estado particular ocorre não é registrada.Se você deve controlar a ação que causou uma transição, você pode especificar um campo de item de trabalho adicional para capturá-la ou você pode definir um valor de motivo.

Voltar ao início

Associar uma transição de estado com uma ação

Você pode usar ações de transição de estado para automatizar as transições de itens de trabalho em vários pontos no seu fluxo de trabalho. Por exemplo, um Team Foundation Server sistema de controle de versão deve oferecer suporte a transições automáticas de itens de trabalho no momento da verificação. Para suportar isso, uma ação "Checkin" foi definida.

Um autor de tipo de item de trabalho pode definir um tipo de item de trabalho "Defeito" que tem um estado chamado "Trabalho" e usar esse item de trabalho quando um desenvolvedor está fazendo alterações. Autor do tipo de item de trabalho pode definir outro estado chamado "Pronto para Build", que significa que o desenvolvedor declarou o código que foi afetado por defeito para estar preparado para a compilação noturna.

O autor pode passar o item de trabalho do estado de "Trabalho" no estado "Pronto para compilar" automaticamente durante uma operação de check-in declarando o seguinte:

<TRANSITION from="Working" to="Ready To Build">
   <ACTIONS>
      <ACTION value="microsoft.vsts.actions.checkin"/>
   </ACTIONS>
</TRANSITION>

Voltar ao início

Detalhes da ação de transição

Use ações de transição de estado para automatizar as transições de itens de trabalho em vários pontos no seu fluxo de trabalho. Você pode considerar os seguintes detalhes de uso sobre ações de transição:

  • Ações de transição são opcionais. Se o estado atual da instância de item de trabalho possui uma entrada de ação para a ação especificada, ela retornará o estado "para". Se não, o valor de retorno será Null. Normalmente, integrações devem tratar valores de retorno nulo. Isso é:

    • Não falhará.

    • Deixe um rastreamento ou registro que indica que a integração fez a transição não automática porque exigia uma ação que não foi encontrada.

  • Para cada tipo de item de trabalho, ações devem ser exclusivas para os pares do estado/ação. Isso significa que os autores de tipo de item de trabalho não é possível especificar vários "para" estados para a mesma ação.

  • No entanto, várias ações na mesma transição têm suporte para permitir várias integrações de transição automática conforme mostrado no exemplo a seguir:

    <TRANSITION from="Working" to="Ready To Build">
       <ACTIONS>
          <ACTION value="Microsoft.VSTS.Actions.Checkin"/>
          <ACTION value="ADatum.Actions.Complete"/>
       </ACTIONS>
    </TRANSITION>
    
  • Nomes de ação são nomes programáticos para o qual você pode usar somente caracteres do inglês.

  • Nomes de ação devem seguir a mesma convenção de namespace de referência como nomes de referência de campo, para evitar conflitos de nome de ação entre fornecedores e clientes. No entanto, esta convenção não é imposta pela ferramenta. Visual Studio ALM usa Microsoft.VSTS.Actions.<your action>.

Verificação de erros de transição automática

Os integradores podem tentar dois tipos de transições automaticamente. A primeira é uma transição automática ocorre devido a uma ação do usuário. A segunda é uma transição automática ocorre por meio da automação autônoma, como uma compilação noturno.

  • Automática de ação do usuário-transições   para esse tipo de transição automática, um usuário está presente para reagir a todos os problemas relacionados à regra que aparecem. Certifique-se de que há suporte para a situação que ocorre quando o autor de um tipo de item de trabalho adiciona um campo obrigatório não reconhece a integração. Para oferecer suporte a essa situação, fazer a transição automática e, em seguida, inspecione o tipo de item de trabalho violações da regra. Se você encontrar alguma, exiba o formulário para o usuário resolva.

  • Automação autônoma auto-transições   deve assumir que nenhum usuário está presente para resolver esses problemas. Nesse caso, a integração caso falhe normalmente. Um log de erros deve indicar que a transição automática foi tentada e fornecer um motivo da falha.

Ao definir o tipo de transição automática, defina a transição para que cada item de trabalho atinge um estado válido no final da transição sem a necessidade de intervenção do usuário. Em outras palavras, todas as regras que são definidas para o estado que está sendo transferido para forem atendidas pelo fornecimento de padrões ou copiado valores para todos os campos. Se qualquer campo se torna inválido após a transição, a transição de estado falhará.

Para impedir que campos se torne inválido, faça o seguinte:

  • Definir um DEFAULTREASON para a transição de estado.

  • Para campos que seria necessários após a transição de estado, use o DEFAULT ou COPY elementos para especificar um valor para o campo da regra.

Por exemplo, você criou a ação de transição Check-In, o que faz a transição do estado de um item de trabalho de "Trabalho" para "Pronto para compilar". Regras do item de trabalho para "Pronto para compilar" exigem que o campo "Resolvido por" seja definido. Em seguida, você deve definir um DEFAULT ou COPY elemento da regra para "ResolvedBy" no TRANSITION seção. Além disso, você definiria um DEFAULTREASON para certificar-se de que o campo necessário pode ser definido sem intervenção do usuário.

Consulte também

Outros recursos

Aplicar uma regra a um campo do item de trabalho

associando uma transição de estado com uma ação