Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Serviços de DevOps do Azure
O Azure DevOps dá suporte à adição e atualização de processos por meio 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 a Ferramenta de Migração de Dados do Azure DevOps. Se você usar o modelo de processo de herança, poderá personalizar o acompanhamento do trabalho por meio da interface do usuário criando um processo de herança. Se você usar o modelo de processo XML local, poderá personalizar um modelo de processo, consulte Carregar ou baixar um modelo de processo e Personalizar um modelo de processo
Para obter mais informações sobre personalização e modelos de processo, consulte Personalizar o acompanhamento do 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 no Azure DevOps. 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 |
|---|---|---|---|
| Rastreamento de Itens de Trabalho | Áreas e Iterações | Construir | Mapeamentos do Microsoft Project |
| Tipos de itens de trabalho (WITs) | Gestão de Testes | Gestão de Laboratório | Relatórios |
| Categorias | Itens de Trabalho | Controlo de Versões | Portal (Produtos do SharePoint) |
| Configuração do processo | Consultas de itens de trabalho |
Pré-requisitos
Para obter orientação sobre como adaptar os Painéis do Azure para alinhá-los com seus requisitos de negócios específicos, consulte Configurar e personalizar Painéis do Azure.
| Categoria | Requerimentos |
|---|---|
| Permissões | - Para criar, excluir ou editar um processo: Membro do grupo Administradores da coleção de projetos ou permissões específicas no nível da coleção Criar processo, Excluir processo, Editar processo ou Excluir um campo da organização definido como Permitir. Para obter mais informações, consulte Personalizar um processo herdado. - Para atualizar quadros: Administrador de Equipe ou um membro do grupo Administradores de Projeto . |
| Acesso | - Mesmo que você tenha acesso Básico ou inferior, você ainda pode alterar um processo se alguém lhe der permissão. - Para atualizar e alterar o tipo de seus itens de trabalho existentes: Membro do projeto. |
| Modelo de processo de projeto | - Possuir o modelo de processo de herança para a coleção de projetos que inclui o projeto. - Para migrar dados para os Serviços de DevOps do Azure, use o Serviço de Importação de Banco de Dados do Team Foundation Server. |
| Conhecimento | - Familiaridade com os modelos de customização e processo. |
Personalizar um processo
Personalizar um processo é mais eficiente quando você começa com um processo bem definido em vez de construir um do zero.
Se você estiver atualizando um processo existente usado anteriormente com o Azure DevOps Server, verifique se ele adere às restrições necessárias para a importação de modelo para evitar erros de validação durante o processo de importação.
Exportar e importar um processo
Execute as seguintes etapas para importar ou exportar um processo:
Inicie sessão na sua organização (
https://dev.azure.com/{Your_Organization}).Selecione
Configurações da organização.
Selecione Processo.
Importante
Se não vir Processo, está a trabalhar a partir de uma versão anterior em que a página Processo não é suportada. Use os recursos suportados para o modelo de processo XML local.
Selecione os três pontos (...) para abrir o menu de contexto do processo XML alojado que deseja exportar. Você pode exportar apenas processos XML hospedados.
Salve o arquivo zip e extraia todos os arquivos dele.
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"/>Aplique personalizações suportadas.
Crie um arquivo zip de todos os arquivos e pastas no diretório raiz.
Personalizações suportadas
Você pode aplicar as seguintes personalizações ao seu processo:
- Adicionar, remover ou modificar um WIT
- Adicionar ou modificar um campo
- Adicione até cinco listas de pendências de portfólio
- Modificar a configuração do processo
- Adicionar listas globais
Diferenças
Os Serviços de DevOps do Azure e o Servidor de DevOps do Azure usam modelos diferentes para relacionar projetos e processos:
- No Servidor de DevOps do Azure, os modelos de processo servem como pontos de partida para projetos, e a personalização tem como escopo projetos individuais.
- Nos Serviços de DevOps do Azure, os processos são compartilhados entre vários projetos e servem como escopo para personalização.
A estrutura e a sintaxe para definir modelos de processo são principalmente consistentes, com apenas pequenas diferenças entre os modelos projetados para os Serviços de DevOps do Azure e o Servidor de DevOps do Azure.
Observação
A migração do XML hospedado para o modelo herdado é suportada apenas nos Serviços de DevOps do Azure, não no Servidor de DevOps do Azure.
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.
Personalizações sem suporte e arquivos de plug-in não referenciados
Qualquer referência aos seguintes objetos em qualquer um dos arquivos de definição XML resulta em um erro de validação na importação:
- Controles personalizados em formulários de item de trabalho
- Tipos de links personalizados
- Fluxo de trabalho global
- Suporte de campo da equipe
- Regras de para e não
- Suporte a regras de correspondência
Os seguintes plug-ins e seus arquivos associados não são usados na definição de um processo, nem usados para atualizar projetos existentes: No entanto, eles são usados para criar objetos ou artefatos quando você cria um novo projeto.
- Classificação
- Consultas de item de trabalho, definidas usando a sintaxe WIQL (Work Item Query Language)
- Gestão de Testes
- Itens de trabalho
Observação
O comprimento do WIQL não deve exceder 32 K caracteres. O sistema não permite que você crie ou execute consultas que excedam esse comprimento.
Os seguintes plug-ins e seus arquivos associados são substituídos por padrões do sistema:
- Construir
- Grupos e permissões
- Laboratório
- Controlo de Versões
Os seguintes plug-ins e seus arquivos associados são ignorados:
- Mapeamentos do Microsoft Project
- Relatórios
- Windows SharePoint Services
Não há suporte para plug-ins personalizados.
Limites de objetos
Ao personalizar um modelo de processo para importação, limite o número de objetos definidos conforme especificado em Limites de objetos de controle de trabalho.
Modelo de processo
Seu arquivo ProcessTemplate.xml deve estar em conformidade com a sintaxe e as regras devem atender às 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 nome e GUID de 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 mais restrições.
- 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
TypeFieldselementos - Está limitado a cinco tarefas acumuladas no portefólio
- Contém apenas uma lista de pendências de carteira não parentais
- Especifica apenas um backlog de carteira principal para cada backlog 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 de definição de ProcessConfiguration.xml
Tipos de item de trabalho
Um WITD elemento e seus elementos filho devem estar em conformidade com a sintaxe e as regras descritas na referência de elemento XML WITD. Além disso, deve satisfazer as seguintes condições:
- Há no máximo 1.024 campos dentro de um único WIT e 1.024 campos em todos os WITs.
- O nome amigável e o atributo obrigatório
refnameatribuídos a um WIT são exclusivos dentro do conjunto de arquivos de definição WIT. - O valor do atributo necessário
refnamenão contém caracteres não permitidos nem usa os namespaces não permitidosSystem.NameeMicrosoft.Name. - Os nomes de referência contêm pelo menos um ponto (.) e todos os outros caracteres são letras sem espaços.
- O elemento
WITDcontém um elementoFORMque define um elementoWebLayoutem conformidade com a sintaxe especificada nos elementos WebLayout e Control.
Campos de item de trabalho
Um FIELDS elemento e seus elementos filho devem estar em conformidade com a sintaxe e as regras descritas em FIELD XML element reference. Além disso, deve satisfazer as seguintes condições:
- O nome amigável e o atributo obrigatório
refnameatribuídos a um WIT são exclusivos dentro do conjunto de arquivos de definição WIT. - O valor do atributo necessário
refnamenão contém caracteres não permitidos nem usa os namespaces não permitidosSystem.NameeMicrosoft.Name. - 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 os seus elementos filho podem conter um elemento GLOBALLIST.
Limitar restrições
- Um
FIELDSelemento é limitado a 1.024 campos. - Um tipo de item de trabalho é limitado a 64 campos de nome de pessoa. Um campo de nome de pessoa é aquele com o atributo e o valor
syncnamechanges=true. - Um
ALLOWEDVALUESelemento ouSUGGESTEDVALUESé limitado a 512LISTITEMelementos. - Um campo é limitado a 1.024 regras.
Campos obrigatórios
| Categoria | Campos a especificar |
|---|---|
| Backlog de configuração do processo | Campos utilizados para os atributos e valores type=Team e type=Order |
| Backlog regular ou carteira em atraso | Campo utilizado para type=Effort |
| Pendências de Tarefas | - Campo usado para type=RemainingWork- Campo usado para type=Activity- ALLOWEDVALUES regra para o campo usado para type=Activity |
Restrições de regras
| Restrição | Detalhes |
|---|---|
| Os elementos da regra de campo não podem especificar os atributos for e not. | Esses atributos não são permitidos em elementos de regra de campo. |
FIELD elementos não podem conter os elementos regra-filho CANNOTLOSEVALUE, NOTSAMEAS, MATCH e PROHIBITEDVALUES. |
Esses elementos subordinados não são suportados dentro de elementos FIELD. |
FIELD As definições para System.Name campos não podem conter regras de campo, exceto para campos específicos. |
Apenas determinados campos podem conter regras específicas, conforme descrito neste artigo. |
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, name, typee outros atributos que um FIELD elemento 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:
| Nome do campo | Nome de referência |
|---|---|
| Atribuído A | System.AssignedTo |
| Autorizado como | System.AuthorizedAs |
| Alterado por | System.ChangedBy |
| Criado por | System.CreatedBy |
| Ativado por | Microsoft.AzureDevOps.Common.ActivatedBy |
| Fechado por | Microsoft.AzureDevOps.Common.ClosedBy |
| Resolvido por | Microsoft.AzureDevOps.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 FIELD definição.
SUGGESTEDVALUES- Regras que contêm valores não identitários.
Exemplo correto
Para limitar os nomes de conta que são válidos num campo de identidade, especifique o elemento com um atributo de nome de grupo VALIDUSER.
<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 criar o grupo nos projetos que o processo atualiza.
Exemplo incorreto
O exemplo a seguir não é válido porque especifica:
- Um
ALLOWEDVALUESelemento. - Um
DEFAULTelemento que especifica a cadeia de caracteres não identitáriavalue="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>
Workflow
Um WORKFLOW elemento 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 de ProcessConfiguration.xml
- Define-se 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 "Em Progresso"
- 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
- Há 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 FORM elemento e seus elementos filho devem estar em conformidade com a sintaxe e as regras descritas na referência do elemento FORM XML.
Um Control elemento não pode especificar um controle personalizado. Não há suporte para controles personalizados.