Partilhar via

Validar e preparar o ambiente do servidor para migração

  • Artigo

A validação envolve a preparação do ambiente atualizado do Azure DevOps Server para migração. Este artigo ajuda-o a resolver problemas comuns. Se não houve erros e todas as verificações de validação foram aprovadas, sua coleção de projeto de equipe estará pronta e você poderá passar para a próxima fase. Examine os arquivos de log para encontrar quaisquer erros, se nem todas as verificações foram aprovadas.

Diagrama do estágio de validação destacado dos sete estágios de migração.

Pré-requisitos

Faça o download da ferramenta de migração de dados mais recente.

Aprenda os tipos de validação de processo

Durante a validação, a Ferramenta de Migração de Dados determina o modelo de processo de destino para cada projeto. Ele atribui automaticamente um dos dois modelos de processo a seguir a cada projeto da coleção:

  • Modelo de processo herdado: Se o projeto foi criado com o modelo de processo Agile, Scrum ou Capability Maturity Model Integration (CMMI) e nunca foi personalizado.
  • Modelo de processo XML hospedado: Se o processo do projeto parece ser personalizado. Um processo personalizado contém campos personalizados, tipos de item de trabalho ou outros tipos de personalizações.

Quando o processo XML hospedado é o modelo de processo de destino, a Ferramenta de Migração de Dados valida se as personalizações podem ser migradas. A Ferramenta de Migração de Dados gera dois arquivos durante a validação:

  • DataMigrationTool.log: Contém o conjunto de erros de validação de processo encontrados na coleção. Corrija todos os erros de processo encontrados para prosseguir com a migração.
  • TryMatchOobProcesses.log: Lista para cada projeto o modelo de processo de destino - Herança ou XML Hospedado. Para projetos definidos para direcionar o modelo de processo XML hospedado, ele explica por que eles são considerados personalizados. Você não precisa corrigir esses erros, mas eles fornecem orientação sobre o que fazer caso você queira migrar para o modelo de processo de herança. Depois que uma coleção é migrada, você pode migrar um projeto para um modelo de processo de herança.

Validar uma coleção de projeto de equipe

Como cada coleção de projeto de equipe corresponde ao seu próprio banco de dados SQL, o processo de validação examina vários aspetos da sua coleção, incluindo:

  • Tamanho do banco de dados da coleção
  • Agrupamento do banco de dados SQL
  • Identidades dos usuários na coleção
  • Personalizações de modelo (processo)

Para iniciar a validação, use a ferramenta migrator. Recomendamos executar a ferramenta migrator a partir de um dos servidores de camada de aplicativo (AT) em seu ambiente do Azure DevOps Server.

Para opções de linha de comando específicas, solicite texto de ajuda usando o seguinte comando:

	Migrator validate /help

A maneira mais comum de iniciar a validação é especificando a URL da coleção de projetos de equipe com a seguinte estrutura:

	Migrator validate /collection:http://localhost:8080/tfs/DefaultCollection

Ver avisos e erros de validação

Quando a ferramenta migrador é concluída, ela gera arquivos de log e resultados exibidos na tela do prompt de comando. Se nenhum erro ocorrer e todas as verificações de validação forem aprovadas, sua coleção de projeto de equipe estará pronta para a próxima fase. Caso as verificações de validação falhem, revise os arquivos de log para identificar erros e resolva-os.

Concentre-se no Migrator.log arquivo, que contém detalhes essenciais sobre as verificações de validação e ajuda a preservar a personalização. Os outros arquivos correspondem a erros de validação específicos com base em seus nomes. Procure a cadeia de caracteres "Validação - Iniciando a validação do projeto 1". Cada projeto é validado. Analise todos os projetos e procure por quaisquer linhas que contenham um prefixo de [Error...

Além disso, a TryMatchOobProcesses.log lista erros relacionados a projetos que usam processos Out-of-Box (OOB) (como Agile, Scrum ou CMMI). Se um projeto usa um processo OOB sem personalizações, o projeto é incluído no modelo herdado. É importante ressaltar que os erros neste arquivo não atrapalham o processo de migração.

Captura de ecrã do ficheiro DataMigrationTool.log gerado pela Ferramenta de Migração de Dados.

Para obter uma lista de erros de validação, consulte Resolver erros de validação. Para cada erro de validação, fornecemos o número do erro, a descrição e o método a ser resolvido. Vários tipos de erro podem aparecer nos logs de verificação de validação. Procure assistência de seu parceiro de DevOps treinado, dos Serviços de Consultoria da Microsoft ou do Suporte Premier da Microsoft para resolver erros encontrados.

Resolver erros de modelo de processo

Os principais erros que encontramos são problemas de modelo de processo. Esses problemas decorrem de projetos de equipe desatualizados que não incorporam os recursos mais recentes do Servidor de DevOps do Azure ou personalizações sem suporte pelos Serviços de DevOps do Azure. Mas, os Serviços de DevOps do Azure dão suporte a uma variedade de personalizações e a validação sinaliza apenas aqueles que exigem pré-migração de resolução. A Ferramenta de Migração de Dados executa uma verificação abrangente de seus modelos para compatibilidade dos Serviços de DevOps do Azure, mas algumas modificações podem ser necessárias.

  • Modelos de processo personalizados ou modelos desatualizados podem causar erros de validação de processo durante a migração.
  • Se você usar um processo OOB Agile, Scrum ou CMMI, verifique se há TryMatchOobProcesses.log erros. Projetos livres de erros são mapeados para processos OOB.
  • Algumas personalizações não funcionam nos Serviços de DevOps do Azure. Reveja a lista de personalização suportada.
  • Para projetos que usam modelos mais antigos, execute o Assistente para Configurar Recursos para atualizar modelos com recursos recentes e reduzir a contagem de erros.
  • Certifique-se de witadmin estar disponível na máquina onde você corrige erros de processo. É essencial para fazer alterações nos modelos de processo.

Considere as seguintes ferramentas para resolver erros de processo:

  • Utilize a ferramenta de linha de comando witadmin.exe incluída nas instalações do Visual Studio. Documentação técnica detalhada sobre como lidar com esses erros está disponível neste link.
  • Automatize a exportação de modelos de processo para cada projeto de equipe usando um comando de ferramenta migrador não documentado: O Migrator valida /collection:http://localhost:8080/tfs/DefaultCollection /SaveProcesses.
  • Explore o TFS Team Project Manager no GitHub (link). Ele permite que você compare projetos de equipe com modelos de processo conhecidos, incluindo modelos prontos para uso.

Para corrigir os erros, altere a sintaxe XML e aplique as alterações de volta ao projeto.

Gorjeta

Recomendamos que você modifique o XML manualmente, em vez de usar o TFS Power Tools.

Para obter o modelo de processo do projeto, adicione o /SaveProcesses parâmetro ao executar o comando Ferramenta de Migração de Dados.

Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region} /SaveProcesses

Este comando extrai o XML do projeto e o coloca na mesma pasta que os logs. Extraia os arquivos zip para sua máquina local para que você possa editar os arquivos.

Agora, corrija o XML. Use os logs do arquivo DataMigrationTool.log para determinar os erros para cada projeto.

Captura de ecrã do ficheiro de registo de processos gerado pela Ferramenta de Migração de Dados.

Alguns erros exigem que você use um witadmin changefield comando. Alterar o nome de um campo é o exemplo mais comum. Para poupar algum tempo, recomendamos que execute o comando witadmin changefield e, em seguida, execute novamente a Ferramenta de Migração de Dados. Isso reexporta o XML com os nomes corrigidos. Caso contrário, corrija manualmente os campos na sintaxe XML também.

Depois de fazer uma correção, aplique as alterações de volta ao Servidor de DevOps do Azure. Dependendo das alterações feitas, você precisa executar um ou mais comandos witadmin. Criamos um script do PowerShell para automatizar esse processo. O script contém todos os comandos witadmin necessários para confirmar todo o processo.

Você pode obter os scripts em Process Customization Scripts. Use o script import/ConformProject.ps1.

.\conformproject.ps1 "<collection url>" "<project name>" "<process template folder>"

Quando o script for concluído, execute novamente a Ferramenta de Migração de Dados para validar a coleção. Siga as etapas 1 a 3 até que a Ferramenta de Migração de Dados não gere mais erros de validação.

Captura de tela do processo de projeto de conformidade no PowerShell.

Gorjeta

Se você é novo em XML e witadmin, sugerimos que faça uma correção de cada vez e, em seguida, esteja em conformidade. Continue esse loop até que todos os erros sejam resolvidos.

Atualizar para um processo do sistema

Se você começou com uma versão mais antiga do Azure DevOps Server, seus projetos provavelmente usam um modelo de processo mais antigo. Se esses projetos não foram atualizados usando o Assistente para Configurar Recursos, a Ferramenta de Migração de Dados detetará erros de processo. Em casos raros, mesmo o assistente pode não resolver problemas antigos relacionados ao processo.

Poderá receber algumas das seguintes mensagens de erro de exemplo:

Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element PortfolioBacklog is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element BugWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element FeedbackRequestWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element FeedbackResponseWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Team.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField RemainingWork.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Order.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Effort.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Activity.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationStartInformation.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationLaunchInstructions.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationType.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF400572: The Project Process Settings must be configured for this feature to be used.

Se você não personalizou seu projeto (por exemplo, campos adicionados, tipos de item de trabalho e assim por diante.), corrigir esses erros é simples. Mas, se você personalizou seu processo, essa abordagem não é suficiente. Você precisa ajustar manualmente os modelos de processo para preservar suas personalizações de serem substituídas.

Faça as seguintes etapas, para cada projeto, para alinhar seu processo:

  1. Identifique o processo inicial com o qual seu projeto começou (Scrum, Agile ou CMMI).
  2. Visite os scripts de personalização de processo no GitHub e faça o download do repositório.
  3. Concentre-se no conteúdo da pasta Migração.
  4. Utilize o script a seguir ConformProject.ps1 para alinhar um projeto de sua escolha com o processo do sistema Agile. Esta ação atualiza todo o projeto para ser Agile.
.\ConformProject.ps1 "<collection url>" "<project name>" "c:\process-customization-scripts\import\agile"

Erros comuns de validação

VS402841: Campo X no tipo de item de trabalho Bug tem syncnamechanges=false mas tem regras que o tornam um campo de identidade. Os campos de identidade devem ter syncnamechanges=true. Atualize seu modelo de processo para incluir essa alteração.

Nos Serviços de DevOps do Azure, adicionamos uma regra para que cada campo de identidade tenha o syncnamechanges=true atributo. No Azure DevOps Server, essa regra não se aplica. Portanto, a Ferramenta de Migração de Dados identifica isso como um problema. Fazer essa alteração no Servidor de DevOps do Azure local não causa nenhum dano.

Execute o comando witadmin changefield . A sintaxe do comando é semelhante ao exemplo a seguir.

witadmin changefield /collection:http://AdventureWorksServer:8080/tfs/DefaultCollection /n:fieldname /syncnamechanges:true

Para obter mais informações sobre o comando witadmin changefield , consulte Gerenciar campos de item de trabalho.

TF402556: Para que o campo System.IterationId seja bem definido, você deve nomeá-lo Iteration ID e definir seu tipo como Integer.

Este erro é frequentemente associado a modelos de processo desatualizados. Para resolvê-lo, você pode executar o Assistente para Configurar Recursos para cada projeto. Como alternativa, você pode executar o seguinte comando para automatizar o processo.

witadmin changefield /collection:http://AdventureWorksServer:8080/tfs/DefaultCollection /n:fieldname /name:newname

TF402571: O elemento necessário BugWorkItems está ausente da Configuração do Processo.

Esse erro é comumente visto quando um processo não foi atualizado por algum tempo. Para corrigi-lo, execute o Assistente para Configurar Recursos para cada projeto.

TF402564: Você definiu XX listas globais. Apenas 64 são permitidos

Os Serviços de DevOps do Azure suportam nativamente 64 listas globais. Esse erro normalmente surge quando há um grande número de pipelines de compilação, pois cada novo pipeline cria uma lista global chamada Builds - TeamProjectName. Para resolver esse erro, remova todas as listas globais desatualizadas.

Repetir verificações de validação

Em cada iteração, corrija erros e realize verificações de validação para resolvê-los, conforme indicado pelos arquivos de log de validação. Persista com esse ciclo até que todos os erros sejam corrigidos e você receba a confirmação de que as verificações de validação da coleção foram bem-sucedidas.

Próximos passos

Prepare-se para a execução do teste