Partilhar via


Personalizar um processo XML hospedado

Serviços de DevOps do Azure

Os Serviços do Azure DevOps suportam a adição e a atualização de processos através de uma experiência administrativa que é um processo de importação baseado na Web. Depois de adicionar um processo, poderá criar um ou mais projetos a partir do mesmo. Pode atualizar o processo em qualquer altura ao importá-lo novamente. As alterações feitas no modelo de processo são, em seguida, aplicadas a todos os projetos que utilizam o processo.

Importante

Com o modelo de processo XML hospedado, você personaliza o controle de trabalho atualizando arquivos de definição XML selecionados de um modelo de processo. Esse recurso está disponível somente quando os dados são migrados para os Serviços de DevOps do Azure usando o Serviço de Importação de Banco de Dados do Team Foundation Server.

Para saber mais sobre personalização e modelos de processo, consulte Personalizar acompanhamento de trabalho.

Um processo é um arquivo zip que contém um conjunto de arquivos interdependentes. Esses arquivos definem os blocos de construção do sistema de rastreamento de item de trabalho e outros subsistemas nos Serviços de DevOps do Azure. Alguns blocos de construção atualizam projetos existentes, enquanto outros se aplicam apenas a novos projetos. Consulte a tabela a seguir para obter a lista completa de blocos de construção.

Usado ao importar/atualizar um processo

Usado ao criar um novo projeto

Substituído por padrões do sistema

Ignorado

Controlo de Itens de Trabalho

WITs

Categorias

Configuração do processo

Áreas e Iterações

Gestão de Testes

Itens de Trabalho

Consultas de item de trabalho

Compilar

Gestão de Laboratório

Controlo de Versões

Mapeamentos do Microsoft Project

Relatórios

Portal (Produtos do SharePoint)

Plug-ins e objetos de processo suportados para importação de processos

Há diferenças entre o que os Serviços de DevOps do Azure suportam e o que o Team Foundation Server local suporta. Para obter um resumo dessas diferenças, consulte Diferenças de personalizações de modelo de processo.

Como personalizar um processo

Quando você personaliza um processo, começar com um processo bem definido é mais fácil do que construir um novo.

Se você atualizar um processo existente que você usou com o Team Foundation Server local, certifique-se de que ele esteja em conformidade com as restrições colocadas em modelos para importação.

Abrir processo de configurações>

Você cria, gerencia e faz personalizações em processos a partir de Configurações>da organização Processo.

  1. Escolha o logotipo do Azure DevOps para abrir Projetos. Em seguida, escolha Configurações da organização.

    Abrir configurações da organização

  2. Em seguida, escolha Processar.

    Configurações da Organização, página Processo

    Importante

    Se você não vir Processo, então você está trabalhando a partir do TFS-2018 ou versão anterior. A página Processo não é suportada. Você deve usar os recursos suportados para o modelo de processo XML local.

Exportar e importar um processo

  1. Na guia Processos, selecione as reticências (...) para abrir o menu de atalho para o processo XML hospedado que você deseja exportar. Você pode exportar apenas processos XML hospedados.

    > Página de processo Opção de menu de processo Exportar XML hospedado

    Salve o arquivo zip e extraia todos os arquivos dele.

  2. Renomeie o processo dentro do arquivo ProcessTemplate.xml localizado no diretório raiz.

    Nomeie o processo para distingui-lo dos existentes.

    <name>MyCompany Agile Process </name>

    Altere o tipo de versão e altere os números principais e secundários. Forneça um GUID distinto para o tipo como neste exemplo:

    <version type="F50EFC58-C2FC-4C66-9814-E395D90778A3" major="1" minor="1"/>

  3. Aplique personalizações suportadas.

  4. Crie um arquivo zip de todos os arquivos e pastas no diretório raiz.

  5. Importe o arquivo zip do seu processo personalizado.

Personalizações suportadas

Você pode aplicar as seguintes personalizações ao seu processo:

A seção a seguir lista as limitações que o sistema impõe.

Restrições

Pode importar até 32 processos para os Serviços do Azure DevOps. Seus processos personalizados devem estar em conformidade com todas as regras resumidas a seguir. Caso contrário, as mensagens de erro de validação poderão aparecer após a importação.

Modelo de processo

Seu arquivo ProcessTemplate.xml deve estar em conformidade com a sintaxe e as regras descritas na referência do elemento XML ProcessTemplate. Além disso, deve satisfazer as seguintes condições:

  • Limita o número de WITs definidos a 64
  • Contém apenas um arquivo de definição Categories.xml
  • Contém apenas um arquivo de definição ProcessConfiguration.xml
  • Usa nomes amigáveis exclusivos em todos os campos e definições WIT

Além disso, seu processo deve passar pelas seguintes verificações de validação:

  • Os nomes de processo são exclusivos e contêm no máximo 155 caracteres Unicode.
    • Um modelo com o mesmo GUID de nome e versão de um processo existente substitui esse processo.
    • Um modelo com o mesmo nome, mas um GUID de versão diferente gera um erro.
    • Os nomes de processo não podem conter os seguintes caracteres especiais: . , ; ' ` : / \ * | ? " & % $ ! + = ( ) [ ] { } < >.
      Consulte Restrições de nomenclatura para obter restrições adicionais.
  • As pastas de processo não contêm arquivos .exe. Mesmo que você possa importar um processo que contenha um arquivo .exe, a criação do projeto falhará.
  • O tamanho total do processo é de, no máximo, 2 GB. Caso contrário, a criação do projeto falhará.

Configuração do processo

O arquivo de definição ProcessConfiguration.xml deve estar em conformidade com a sintaxe e as regras descritas na referência do elemento XML ProcessConfiguration. Além disso, deve satisfazer as seguintes condições:

  • Especifica todos os elementos TypeFields
  • Está limitado a cinco pendências de carteira
  • Contém apenas uma lista de pendências de carteira não parentais
  • Especifica apenas uma lista de pendências de carteira pai para cada lista de pendências de carteira subordinada
  • Contém mapeamentos de estado para metaestado do fluxo de trabalho necessários e não faz referência a metaestados sem suporte

Categorias

O arquivo de definição Categories.xml deve estar em conformidade com a sintaxe e as regras descritas em Referência de elemento XML de categorias. Além disso, deve satisfazer as seguintes condições:

  • Está limitado a 32 categorias
  • Define todas as categorias referenciadas no arquivo ProcessConfiguration.xml

Tipos de item de trabalho

Um elemento WITD e seus elementos filho devem estar em conformidade com a sintaxe e as regras descritas na referência do elemento WITD XML. Além disso, deve satisfazer as seguintes condições:

  • Há no máximo 512 campos dentro de um único WIT e 512 campos em todos os WITs.
  • O nome amigável e o atributo refname necessário atribuídos a um WIT são exclusivos dentro do conjunto de arquivos de definição WIT.
  • O valor do atributo refname necessário não contém caracteres não permitidos nem usa o sistema de namespaces não permitidos.Nome e Microsoft.Nome.
  • Os nomes de referência contêm pelo menos um ponto (.) e todos os outros caracteres são letras sem espaços.
  • O elemento WITD contém um elemento FORM que define um elemento WebLayout em conformidade com a sintaxe especificada nos elementos WebLayout e Control.

Campos de item de trabalho

Um elemento FIELDS e seus elementos filho devem estar em conformidade com a sintaxe e as regras descritas na referência do elemento XML FIELD. Além disso, deve satisfazer as seguintes condições:

  • O nome amigável e o atributo refname necessário atribuídos a um WIT são exclusivos dentro do conjunto de arquivos de definição WIT.
  • O valor do atributo refname necessário não contém caracteres não permitidos nem usa o sistema de namespaces não permitidos.Nome e Microsoft.Nome.
  • Os nomes de referência contêm pelo menos um ponto (.) e todos os outros caracteres são letras sem espaços.

Um elemento FIELD e seus elementos filho podem conter um elemento GLOBALLIST .

Limitar restrições

  • Um elemento FIELDS é limitado a 512 campos.
  • Um tipo de item de trabalho é limitado a 64 campos de nome de pessoa. Um campo de nome de pessoa é um com o atributo e o valor syncnamechanges=true.
  • Um elemento ALLOWEDVALUES ou SUGGESTEDVALUES é limitado a 512 elementos LISTITEM .
  • Um campo é limitado a 1.024 regras.

Campos obrigatórios

Os seguintes campos são especificados no arquivo ProcessConfiguration.xml:

  • Para todos os WITs em uma categoria que define uma lista de pendências de configuração de processo, especifique os campos usados para os atributos e valores type=Team e type=Order.
  • Para todos os WITs em uma categoria que define uma lista de pendências regular ou uma lista de pendências de portfólio, especifique o campo usado para type=Effort.
  • Para todos os WITs na categoria que define o elemento TaskBacklog , especifique:
    • O campo utilizado para type=RemainingWork.
    • O campo utilizado para type=Activity.
    • A regra ALLOWEDVALUES para o campo usado para type=Activity.

Restrições de regras

Além das restrições de regra de campo padrão , as seguintes restrições são aplicadas:

  • Os elementos da regra de campo não podem especificar os atributos para e não .
  • Os elementos FIELD não podem conter os elementos da regra filho CANNOTLOSEVALUE, NOTSAMEAS, MATCH e PROHIBITEDVALUES.
  • Exceto para os seguintes campos, definições de FIELD para Sistema.Os campos de nome não podem conter regras de campo.
    • System.Title pode conter as regras REQUIRED e DEFAULT.
    • System.Description pode conter as regras REQUIRED e DEFAULT.
    • System.AssignedTo pode conter as regras REQUIRED, DEFAULT, ALLOWEXISTINGVALUE e VALIDUSER.
    • System.ChangedBy pode conter as regras REQUIRED, DEFAULT, ALLOWEXISTINGVALUE e VALIDUSER.

Nomes e atributos consistentes

Dentro de um processo ou de uma coleção de projeto, nome, tipo e outros atributos que um elemento FIELD define devem ser os mesmos em todas as definições WIT.

Campos de identidade

Os campos de identidade correspondem aos campos usados para conter nomes de contas, usuários ou grupos. Os seguintes campos principais do sistema são codificados como campos de identidade:

  • Atribuído a (System.AssignedTo)
  • Autorizado como (System.AuthorizedAs)
  • Alterado por (System.ChangedBy)
  • Criado por (System.CreatedBy)
  • Ativado por (Microsoft.VSTS.Common.ActivatedBy)
  • Fechado por (Microsoft.VSTS.Common.ClosedBy)
  • Resolvido por (Microsoft.VSTS.Common.ResolvedBy)
Adicionar um campo de identidade personalizado

Um campo de cadeia de caracteres é reconhecido como um campo de identidade quando você especifica o atributo syncnamechanges como True.

Restrições de regras em campos de identidade

Para a versão atual da importação de processos, não especifique nenhuma das seguintes regras dentro de uma definição FIELD .

  • VALORES SUGERIDOS
  • Regras que contêm valores não identitários.
Exemplo correto

Para limitar os nomes de conta que são válidos em um campo de identidade, especifique o elemento com um atributo de nome de VALIDUSER grupo.

    <FIELD name="Project Manager" refname="Fabrikam.ProgramManager" type="String" reportable="dimension" syncnamechanges="true">
        <ALLOWEXISTINGVALUE />
        <VALIDUSER group="[PROJECT]\Program Manager Group" />
        <HELPTEXT>The program manager responsible for signing off on the user story.</HELPTEXT>
    </FIELD>

Antes de importar o processo, certifique-se de que criou o grupo nos projetos que o processo atualiza.

Exemplo incorreto

O exemplo a seguir não é válido porque especifica:

  • Um ALLOWEDVALUES elemento.
  • Um DEFAULT elemento que especifica a cadeia de caracteres não identitária value="Not Assigned".
    <FIELD name="Project Manager" refname="Fabrikam.ProgramManager" type="String" reportable="dimension" syncnamechanges="true">
        <ALLOWEXISTINGVALUE />
        <ALLOWEDVALUES>
          <LISTITEM value="[PROJECT]\Program Manager Group" />
          <LISTITEM value="Not Assigned" />
        </ALLOWEDVALUES>
        <DEFAULT from="value" value="Not Assigned" />
        <VALIDUSER />
        <HELPTEXT>The program manager responsible for signing off on the user story.</HELPTEXT>
    </FIELD>

Fluxo de Trabalho

Um elemento WORKFLOW e seus elementos filho devem estar em conformidade com a sintaxe e as regras descritas na referência do elemento XML WORKFLOW. Além disso, deve satisfazer as seguintes condições:

  • Limita cada WIT a 16 estados de fluxo de trabalho
  • Define todos os estados do fluxo de trabalho que são mapeados para metaestados no arquivo de definição ProcessConfiguration
  • Define uma transição entre todos os estados do fluxo de trabalho mapeados para a categoria de estado "Proposto" e os estados do fluxo de trabalho mapeados para a categoria de estado "InProgress"
  • Define uma transição entre todos os estados do fluxo de trabalho mapeados para a categoria de estado "InProgress" e os estados do fluxo de trabalho mapeados para a categoria de estado "Concluído".

Para obter uma descrição da categoria de estado e mapeamentos, consulte Estados de fluxo de trabalho e categorias de estado.

Listas globais

Para o modelo de processo XML hospedado, os seguintes limites são colocados na importação de lista global:

  • Existem no máximo 64 listas globais.
  • São no máximo 1.024 itens por lista.
  • Aproximadamente 10.000 itens podem ser definidos no total entre todas as listas globais especificadas em todos os WITs.

Layout do formulário

Um elemento FORM e seus elementos filho devem estar em conformidade com a sintaxe e as regras descritas na referência do elemento FORM XML.

Um elemento Control não pode especificar um controle personalizado. Não há suporte para controles personalizados.