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

  • Artigo

A validação envolve a preparação do ambiente atualizado do Servidor de DevOps do Azure para migração. Este artigo ajuda você a solucionar problemas comuns. Se não houver erros e todas as verificações de validação forem aprovadas, sua coleção de projetos 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 de destacado Validar estágio dos sete estágios de migração.

Pré-requisitos

Baixe a ferramenta de migração de dados mais recente.

Aprender 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 na 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 parecer 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 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 aspectos de 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 migrador de um dos servidores de camada de aplicativo (AT) em seu ambiente do Servidor de DevOps do Azure.

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 projeto de equipe com a seguinte estrutura:

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

Exibir 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 arquivo, que contém detalhes essenciais sobre as verificações de validação e ajuda a preservar a Migrator.log personalização. Os outros arquivos correspondem a erros de validação específicos com base em seus nomes. Procure a string "Validação - Iniciando a validação do projeto 1". Cada projeto é validado. Examine todos os projetos e procure por quaisquer linhas que contenham um prefixo de [Error...

Além disso, lista TryMatchOobProcesses.log erros relacionados a projetos que usam processos OOB (Out-of-Box) (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 erros nesse arquivo não atrapalham o processo de migração.

Captura de tela do arquivo 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 ajuda de seu parceiro de DevOps treinado, dos Serviços de Consultoria da Microsoft ou do Suporte Premier da Microsoft para resolver os 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 de personalizações sem suporte dos Serviços de DevOps do Azure. Mas, os Serviços de DevOps do Azure oferecem 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 mapeiam para processos OOB.
  • Algumas personalizações não funcionam nos Serviços de DevOps do Azure. Revise a lista de personalização com suporte.
  • 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.
  • Verifique se witadmin está 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. A 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 da ferramenta migrator não documentado: O Migrator valida /collection:http://localhost:8080/tfs/DefaultCollection /SaveProcesses.
  • Explore o Gerenciador de Projetos da Equipe do TFS 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.

Dica

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

Esse 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 tela do arquivo de log do processo gerado pela Ferramenta de Migração de Dados.

Alguns erros exigem que você use um witadmin changefield comando. Alterar um nome de campo é o exemplo mais comum. Para economizar algum tempo, recomendamos que você 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 em conformidade no PowerShell.

Dica

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

Atualização 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 detectará erros de processo. Em casos raros, mesmo o assistente pode não resolver problemas antigos relacionados ao processo.

Você pode 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 que suas personalizações sejam 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 processos no GitHub e faça 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 Servidor de DevOps do Azure, 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.

Esse erro geralmente está 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 dão suporte nativo a 64 listas globais. Esse erro geralmente ocorre 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 os 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 de coleta foram bem-sucedidas.

Próximas etapas

Preparar-se para a execução do teste