Personalizar um processo XML Alojado

  • Artigo

Azure DevOps Services

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 alojado, pode personalizar o controlo de trabalho ao atualizar ficheiros de definição XML selecionados de um modelo de processo. Esta funcionalidade só está disponível quando os dados são migrados para os Serviços de DevOps do Azure através da utilização do Serviço de Importação da Base de Dados do Team Foundation Server.

Para saber mais sobre modelos de personalização e processos, veja Personalizar o controlo de trabalho.

Um processo é um ficheiro zip que contém um conjunto de ficheiros interdependentes. Estes ficheiros definem os blocos modulares do sistema de controlo de itens de trabalho e outros subsistemas nos Serviços de DevOps do Azure. Alguns blocos modulares atualizam projetos existentes, enquanto outros aplicam-se apenas a novos projetos. Consulte a tabela seguinte para obter a lista completa de blocos modulares.

Utilizado ao importar/atualizar um processo

Utilizado ao criar um novo projeto

Substituído por predefiniçõ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 Itens de Trabalho

Compilar

Gestão de Laboratórios

Controlo de Versões

Mapeamentos do Microsoft Project

Relatórios

Portal (Produtos SharePoint)

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

Existem diferenças entre o que os Serviços de DevOps do Azure suportam e o que o Team Foundation Server no local suporta. Para obter um resumo destas diferenças, veja Diferenças nas personalizações do modelo de processo.

Como personalizar um processo

Ao personalizar um processo, começar com um processo bem definido é mais fácil do que criar um novo.

Se atualizar um processo existente que utilizou com o Team Foundation Server no local, certifique-se de que está em conformidade com as restrições colocadas nos modelos para importação.

Abrir Processo de Definições>

Pode criar, gerir e efetuar personalizações a processos a partir do Processo de definições>da Organização.

  1. Escolha o logótipo do Azure DevOps para abrir Projetos. Em seguida, selecione Definições da organização.

    Abrir definições da Organização

  2. Em seguida, selecione Processo.

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

    Importante

    Se não vir Processo, significa que está a trabalhar a partir do TFS-2018 ou versão anterior. A página Processo não é suportada. Tem de utilizar as funcionalidades suportadas para o modelo de processo XML no local.

Exportar e importar um processo

  1. No separador Processos , selecione as reticências (...) para abrir o menu de atalho do processo XML Alojado que pretende exportar. Só pode exportar processos XML alojados.

    Opção de menu Exportar Processo XML Alojado da página > de processos

    Guarde o ficheiro zip e extraia todos os ficheiros do mesmo.

  2. Mude o nome do processo no ficheiro ProcessTemplate.xml localizado no diretório de raiz.

    Atribua um nome ao processo para o distinguir dos existentes.

    <name>MyCompany Agile Process </name>

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

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

  3. Aplicar personalizações suportadas.

  4. Crie um ficheiro zip de todos os ficheiros e pastas no diretório de raiz.

  5. Importe o ficheiro zip do seu processo personalizado.

Supported customizations (Personalizações avançadas)

Pode aplicar as seguintes personalizações ao seu processo:

A secção seguinte lista as limitações impostas pelo sistema.

Restrições

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

Modelo de processo

O ficheiro ProcessTemplate.xml tem de estar em conformidade com a sintaxe e as regras descritas na referência de elementos XML ProcessTemplate. Além disso, tem de cumprir as seguintes condições:

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

Além disso, o processo tem de passar as seguintes verificações de validação:

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

Configuração do processo

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

  • Especifica todos os elementos TypeFields
  • Está limitado a cinco atrasos de portefólio
  • Contém apenas um atraso de portefólio nãoparado
  • Especifica apenas um registo de tarefas pendentes de portefólio principal para cada registo de tarefas pendentes de portefólio subordinado
  • Contém mapeamentos de estado para metaestado do fluxo de trabalho necessários e não faz referência a metaestados não suportados

Categorias

O ficheiro de definição Categories.xml tem de estar em conformidade com a sintaxe e as regras descritas na referência de elementos XML de Categorias. Além disso, tem de cumprir as seguintes condições:

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

Tipos de itens de trabalho

Um elemento WITD e os respetivos elementos subordinados têm de estar em conformidade com a sintaxe e as regras descritas na referência de elementos WITD XML. Além disso, tem de cumprir as seguintes condições:

  • Existem, no máximo, 512 campos num único WIT e 512 campos em todos os WITs.
  • O nome amigável e o atributo refname necessário atribuído a um WIT são exclusivos no conjunto de ficheiros de definição wit.
  • O valor do atributo refname necessário não contém carateres não permitidos nem utiliza o Sistema de espaços de nomes não permitido. Nome e Microsoft. Nome.
  • Os nomes de referência contêm, pelo menos, um ponto final (.) e todos os outros carateres 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 do item de trabalho

Um elemento FIELDS e os respetivos elementos subordinados têm de estar em conformidade com a sintaxe e as regras descritas na referência de elementos XML de CAMPO. Além disso, tem de cumprir as seguintes condições:

  • O nome amigável e o atributo refname necessário atribuído a um WIT são exclusivos no conjunto de ficheiros de definição wit.
  • O valor do atributo refname necessário não contém carateres não permitidos nem utiliza o Sistema de espaços de nomes não permitido. Nome e Microsoft. Nome.
  • Os nomes de referência contêm, pelo menos, um ponto final (.) e todos os outros carateres são letras sem espaços.

Um elemento FIELD e os respetivos elementos subordinados podem conter um elemento GLOBALLIST .

Limitar restrições

  • Um elemento FIELDS está limitado a 512 campos.
  • Um tipo de item de trabalho está 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 está limitado a 512 elementos LISTITEM .
  • Um campo está limitado a 1024 regras.

Campos necessários

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

  • Para todos os WITs numa categoria que define um registo de tarefas pendentes de configuração de processos, especifique os campos utilizados para os atributos e valores type=Team e type=Order.
  • Para todos os WITs numa categoria que define um registo de tarefas pendentes regulares ou um registo de tarefas pendentes de portefólio, especifique o campo utilizado 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 utilizado para type=Activity.

Restrições de regras

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

  • Os elementos de regra de campo não podem especificar os atributos para e não .
  • Os elementos DE CAMPO não podem conter os elementos de regra subordinada CANNOTLOSEVALUE, NOTSAMEAS, MATCH e PROHIBITEDVALUES.
  • Exceto para os seguintes campos, Definições de CAMPO para Sistema. Os campos de nome não podem conter regras de campo.
    • System.Title pode conter as regras NECESSÁRIO EPREDEFINIDO.
    • System.Description pode conter as regras NECESSÁRIO E PREDEFINIDO.
    • 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 projetos, nome, tipo e outros atributos que um elemento FIELD define têm de ser os mesmos em todas as definições de WIT.

Campos de identidade

Os campos de identidade correspondem aos campos utilizados para conter nomes de conta, utilizador ou grupo. Os seguintes campos do sistema principal são hard-coded como campos de identidade:

  • Atribuído a (System.AssignedTo)
  • Authorized As (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 é reconhecido como um campo de identidade quando especifica o atributo syncnamechanges como Verdadeiro.

Restrições de regras em campos de identidade

Para a versão atual da importação do processo, não especifique nenhuma das seguintes regras numa definição CAMPO .

  • SUGGESTEDVALUES
  • Regras que contêm valores de não identidade.
Exemplo correto

Para limitar os nomes de conta válidos num campo de identidade, especifique o VALIDUSER elemento com um atributo de nome de 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 seguinte não é válido porque especifica:

  • Um ALLOWEDVALUES elemento.
  • Um DEFAULT elemento que especifica a cadeia de não identificação 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 FLUXO DE TRABALHO e os respetivos elementos subordinados têm de estar em conformidade com a sintaxe e as regras descritas na referência do elemento XML WORKFLOW. Além disso, tem de cumprir as seguintes condições:

  • Limita cada WIT a 16 estados de fluxo de trabalho
  • Define todos os estados do fluxo de trabalho mapeados para metaestados no ficheiro de definição ProcessConfiguration
  • Define uma transição entre todos os estados de fluxo de trabalho mapeados para a categoria de estado "Proposto" e os estados do fluxo de trabalho mapeados para a categoria de estado "Entrada"
  • Define uma transição entre todos os estados de 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 dos mapeamentos, veja Estados do fluxo de trabalho e categorias de estado.

Listas globais

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

  • Existem, no máximo, 64 listas globais.
  • Existem, no máximo, 512 itens por lista.
  • Aproximadamente 10 000 itens podem ser definidos no total entre todas as listas globais especificadas em todos os WITs.

Esquema de formulário

Um elemento FORM e os respetivos elementos subordinados têm de estar em conformidade com a sintaxe e as regras descritas na referência do elemento FORM XML.

Um elemento Controlo não pode especificar um controlo personalizado. Os controlos personalizados não são suportados.