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

A validação envolve a preparação do ambiente atualizado de Azure DevOps Server 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 erros se nem todas as verificações forem aprovadas.

Pré-requisitos

Baixe a 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 para 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 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 diretrizes 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 projetos de equipe

Como cada coleção de projetos 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 seu banco de dados de coleção
• Agrupamento do banco de dados SQL
• Identidades de usuários na coleção
• Personalizações de modelo (processo)

Para iniciar a validação, use a ferramenta migradora. É recomendável executar a ferramenta migradora de um dos servidores de camada de aplicativo (AT) em seu ambiente Azure DevOps Server.

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

cmdline

	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:

cmdline

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

Exibir avisos e erros de validação

Quando a ferramenta migradora é 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 projetos 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. Pesquise a cadeia de caracteres "Validação - Iniciando a validação do projeto 1". Cada projeto é validado. Examine todos os projetos e procure por linhas que contenham um prefixo de [Error...

Além disso, o TryMatchOobProcesses.log lista erros relacionados a projetos que usam processos prontos para uso (OOB) (como Agile, Scrum ou CMMI). Se um projeto usar um processo OOB sem personalizações, o projeto será incluído no modelo herdado. É importante ressaltar que os erros nesse arquivo não atrapalham o processo de migração.

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 Azure DevOps Server recursos mais recentes ou personalizações sem suporte por Azure DevOps Services. No entanto, Azure DevOps Services dá suporte a uma variedade de personalizações e a validação sinaliza apenas aquelas 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 Azure DevOps Services, 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 TryMatchOobProcesses.log há erros. Projetos sem erros são mapeados para processos OOB.
• Algumas personalizações não funcionam em Azure DevOps Services. Examine 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.
• Certifique-se de que witadmin esteja disponível na máquina em que você corrige os erros do processo. É essencial para fazer alterações nos modelos de processo.
• As regras For e Not devem ser comentadas ou removidas do modelo de processo antes de tentar a migração. Essas regras têm suporte no Azure DevOps Service, mas não têm suporte como parte do processo de migração. Depois que sua coleção for migrada, você poderá adicionar essas regras de volta ao modelo de processo.

Considere as seguintes ferramentas para resolver erros de processo:

• Utilize a witadmin.exe ferramenta de linha de comando 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 de ferramenta de migração não documentada: O Migrator valida /collection:http://localhost:8080/tfs/DefaultCollection /SaveProcesses.
• Explore o Gerente 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 Data Migration Tool.

cmdline

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 de cada projeto.

Alguns erros exigem que você use um witadmin changefield comando. Alterar o nome de um 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 Azure DevOps Server. 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 Scripts de personalização de processos. Use o script import/ConformProject.ps1.

cmdline

.\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.

Dica

Se você é novo em XML e witadmin, sugerimos que você 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 usarão um modelo de processo mais antigo. Se esses projetos não tiverem sido 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:

no-highlight

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 evitar que suas personalizações sejam substituídas.

Execute 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 baixe o 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. Essa ação atualiza todo o projeto para ser Agile.

cmdline

.\ConformProject.ps1 "<collection url>" "<project name>" "c:\process-customization-scripts\import\agile"  

Erros comuns de validação

VS402841: O 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.

Em Azure DevOps Services, adicionamos uma regra para que cada campo de identidade tenha o syncnamechanges=true atributo. Em 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 em Azure DevOps Server local não causa nenhum dano.

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

cmdline

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 como ID de Iteração e definir seu tipo como Integer.

Esse erro geralmente está associado a modelos de processo desatualizados. Para resolver isso, você pode executar o Assistente de Configuração de Recursos para cada projeto. Como alternativa, você pode executar o seguinte comando para automatizar o processo.

cmdline

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

TF402571: O elemento necessário BugWorkItems está ausente na 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

Azure DevOps Services dá suporte nativo a 64 listas globais. Esse erro normalmente surge quando há um grande número de pipelines de build, 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, resolva 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 da coleção foram bem-sucedidas.

Próximas etapas

Prepare-se para o teste

Artigos relacionados

• witadmin: Personalizar e gerenciar objetos para acompanhar o trabalho
• Diferenças entre Azure DevOps Services e Azure DevOps Server personalizações de modelo de processo
• Configurar recursos após Azure DevOps Server atualização
• Resolver erros de validação
• Definir listas globais em Azure DevOps Server
• Scripts do PowerShell de personalização de processos