Compartir vía

Validación y preparación del entorno de servidor para la migración

  • Artículo

La validación implica preparar el entorno de Azure DevOps Server actualizado para la migración. Este artículo le ayuda a solucionar problemas comunes. Si no se han producido errores y se han superado todas las comprobaciones de validación, la colección de proyectos de equipo está lista y puede pasar a la siguiente fase. Examine los archivos de registro para buscar errores si no se pasan todas las comprobaciones.

Diagrama de la fase Validada resaltada de las siete fases de migración.

Requisitos previos

Descargue la herramienta de migración de datos más reciente.

Más información sobre los tipos de validación de procesos

Durante la validación, la Herramienta de migración de datos determina el modelo de proceso de destino para cada proyecto. Asigna automáticamente uno de los dos modelos de proceso siguientes a cada proyecto de la colección:

  • Modelo de proceso heredado: si el proyecto se creó con la plantilla de proceso Agile, Scrum o Capability Maturity Model Integration (CMMI) y nunca se personalizó.
  • Modelo de proceso XML hospedado: si el proceso del proyecto parece personalizarse. Un proceso personalizado contiene campos personalizados, tipos de elementos de trabajo u otros tipos de personalizaciones.

Cuando el proceso XML hospedado es el modelo de proceso de destino, la herramienta de migración de datos valida si se pueden migrar las personalizaciones. La herramienta de migración de datos genera dos archivos durante la validación:

  • DataMigrationTool.log: contiene el conjunto de errores de validación de procesos encontrados en la colección. Corrija todos los errores de proceso encontrados para continuar con la migración.
  • TryMatchOobProcesses.log: muestra para cada proyecto el modelo de proceso de destino: herencia o XML hospedado. En el caso de los proyectos que se establecen como destino del modelo de proceso XML hospedado, se explica por qué se consideran personalizados. No es necesario corregir estos errores, pero proporcionan instrucciones sobre qué hacer en caso de que quiera migrar al modelo de proceso de herencia. Una vez migrada una colección, puede migrar un proyecto a un modelo de proceso de herencia.

Validar una colección de proyectos de equipo

Dado que cada colección de proyectos de equipo corresponde a su propia base de datos SQL, el proceso de validación examina varios aspectos de la colección, entre los que se incluyen:

  • Tamaño de la base de datos de recopilación
  • Intercalación de la base de datos SQL
  • Identidades de los usuarios de la colección
  • Personalizaciones de plantillas (proceso)

Para iniciar la validación, use la herramienta de migración. Se recomienda ejecutar la herramienta de migración desde uno de los servidores de nivel de aplicación (AT) en el entorno de Azure DevOps Server.

Para obtener opciones de línea de comandos específicas, solicite texto de ayuda mediante el siguiente comando:

	Migrator validate /help

La manera más común de iniciar la validación es especificando la dirección URL de la colección de proyectos de equipo con la estructura siguiente:

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

Visualización de advertencias y errores de validación

Cuando se completa la herramienta de migración, genera archivos de registro y resultados mostrados en la pantalla del símbolo del sistema. Si no se producen errores y se pasan todas las comprobaciones de validación, la colección de proyectos de equipo estará lista para la siguiente fase. En caso de que se produzca un error en las comprobaciones de validación, revise los archivos de registro para identificar errores y, a continuación, solucione los errores.

Céntrese en el Migrator.log archivo, que contiene detalles esenciales sobre las comprobaciones de validación y le ayuda a conservar la personalización. Los demás archivos corresponden a errores de validación específicos en función de sus nombres. Busque la cadena "Validation - Starting validation of project 1" (Validación: inicio de la validación del proyecto 1). Cada proyecto se valida. Examinar todos los proyectos y buscar cualquier línea que contenga un prefijo de [Error...

Además, enumera TryMatchOobProcesses.log los errores relacionados con los proyectos que usan procesos De serie (OOB) (como Agile, Scrum o CMMI). Si un proyecto usa un proceso de OOB sin personalizaciones, el proyecto se incluye en el modelo heredado. Importantemente, los errores de este archivo no dificultan el proceso de migración.

Captura de pantalla del archivo DataMigrationTool.log generado por la herramienta de migración de datos.

Para obtener una lista de errores de validación, consulte Resolución de errores de validación. Para cada error de validación, se proporcionó el número de error, la descripción y el método que se va a resolver. Es posible que aparezcan varios tipos de error en los registros de comprobación de validación. Busque ayuda del partner de DevOps entrenado, los servicios de consultoría de Microsoft o el soporte técnico Premier de Microsoft para resolver los errores detectados.

Resolución de errores de plantilla de proceso

Los errores principales que encontramos son problemas de plantilla de proceso. Estos problemas se derivan de proyectos de equipo obsoletos que no incorporan las características más recientes de Azure DevOps Server o las personalizaciones no admitidas por Azure DevOps Services. Sin embargo, Azure DevOps Services admite una serie de personalizaciones y la validación solo marca las que requieren la premigración de resolución. La herramienta de migración de datos realiza una comprobación completa de las plantillas para la compatibilidad de Azure DevOps Services, pero es posible que sea necesario realizar algunas modificaciones.

  • Las plantillas de proceso personalizadas o las plantillas obsoletas pueden provocar errores de validación de procesos durante la migración.
  • Si usa un proceso de OOB Agile, Scrum o CMMI, compruebe si hay TryMatchOobProcesses.log errores. Los proyectos sin errores se asignan a los procesos de OOB.
  • Algunas personalizaciones no funcionan en Azure DevOps Services. Revise la lista de personalización admitida.
  • En el caso de los proyectos que usan plantillas anteriores, ejecute el Asistente para configurar características para actualizar plantillas con características recientes y reducir el número de errores.
  • Asegúrese de que witadmin está disponible en la máquina donde se corrigen errores de proceso. Es esencial para realizar cambios en las plantillas de proceso.
  • Para y No las reglas deben comentarse o quitarse de la plantilla de proceso antes de intentar la migración. Estas reglas se admiten en Azure DevOps Service, pero no se admiten como parte del proceso de migración. Una vez migrada la colección, puede volver a agregar estas reglas a la plantilla de proceso.

Tenga en cuenta las siguientes herramientas para resolver errores de proceso:

  • Use la herramienta de línea de comandos witadmin.exe incluida con las instalaciones de Visual Studio. En este vínculo encontrará documentación técnica detallada sobre cómo solucionar estos errores.
  • Automatice la exportación de plantillas de proceso para cada proyecto de equipo mediante un comando de herramienta de migración no documentada: Migrator valida /collection:http://localhost:8080/tfs/DefaultCollection /SaveProcesses.
  • Explore el Administrador de proyectos de equipo de TFS en GitHub (vínculo). Permite comparar proyectos de equipo con plantillas de proceso conocidas, incluidas las plantillas integradas.

Para corregir los errores, cambie la sintaxis XML y vuelva a aplicar los cambios al proyecto.

Sugerencia

Se recomienda modificar el XML manualmente, en lugar de usar TFS Power Tools.

Para obtener la plantilla de proceso del proyecto, agregue el /SaveProcesses parámetro al ejecutar el comando Herramienta de migración de datos.

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

Este comando extrae el XML del proyecto y lo coloca en la misma carpeta que los registros. Extraiga los archivos ZIP en la máquina local para que pueda editar los archivos.

Ahora, corrija el XML. Use los registros del archivo DataMigrationTool.log para determinar los errores de cada proyecto.

Captura de pantalla del archivo de registro de procesos generado por la herramienta de migración de datos.

Algunos errores requieren que use un witadmin changefield comando . Cambiar un nombre de campo es el ejemplo más común. Para ahorrar tiempo, se recomienda ejecutar el comando witadmin changefield y, a continuación, volver a ejecutar la herramienta de migración de datos. Al hacerlo, vuelva a exportar el XML con los nombres corregidos. De lo contrario, corrija manualmente los campos en la sintaxis XML.

Una vez que realice una corrección, vuelva a aplicar los cambios a Azure DevOps Server. En función de los cambios realizados, debe ejecutar uno o varios comandos witadmin. Hemos creado un script de PowerShell para automatizar este proceso. El script contiene todos los comandos witadmin necesarios para confirmar todo el proceso.

Puede obtener los scripts en Scripts de personalización de procesos. Use el script import/ConformProject.ps1.

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

Cuando se complete el script, vuelva a ejecutar la herramienta de migración de datos para validar la colección. Siga los pasos del 1 al 3 hasta que la herramienta de migración de datos no genere más errores de validación.

Captura de pantalla del proceso de cumplimiento del proyecto en PowerShell.

Sugerencia

Si no está familiarizado con XML y witadmin, le sugerimos que realice una corrección a la vez y, a continuación, se ajuste. Continúe este bucle hasta que se resuelvan todos los errores.

Actualización a un proceso del sistema

Si comenzó con una versión anterior de Azure DevOps Server, es probable que los proyectos usen una plantilla de proceso anterior. Si estos proyectos no se actualizaron mediante el Asistente para configurar características, la herramienta de migración de datos detecta errores de proceso. En raras ocasiones, incluso el asistente podría no resolver problemas relacionados con procesos antiguos.

Es posible que reciba algunos de los siguientes mensajes de error de ejemplo:

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.

Si no personalizó el proyecto (por ejemplo, campos agregados, tipos de elementos de trabajo, etc.), corregir estos errores es sencillo. Pero, si ha personalizado el proceso, este enfoque no es suficiente. Debe ajustar manualmente las plantillas de proceso para conservar las personalizaciones que se sobrescriben.

Realice los pasos siguientes, para cada proyecto, para alinear el proceso:

  1. Identifique el proceso inicial con el que se inició el proyecto (Scrum, Agile o CMMI).
  2. Visite scripts de personalización de procesos en GitHub y descargue el repositorio.
  3. Céntrese en el contenido de la carpeta Migración.
  4. Use el siguiente ConformProject.ps1 script para alinear un proyecto de su elección con el proceso del sistema Agile. Esta acción actualiza todo el proyecto para que sea Agile.
.\ConformProject.ps1 "<collection url>" "<project name>" "c:\process-customization-scripts\import\agile"

Errores de validación comunes

VS402841: el campo X en el tipo de elemento de trabajo Error tiene syncnamechanges=false, pero tiene reglas que lo convierten en un campo de identidad. Los campos de identidad deben tener syncnamechanges=true. Actualice la plantilla de proceso para incluir este cambio.

En Azure DevOps Services, agregamos una regla para que cada campo de identidad tenga el syncnamechanges=true atributo . En Azure DevOps Server, esa regla no se aplica. Por lo tanto, la herramienta de migración de datos lo identifica como un problema. Realizar este cambio en Azure DevOps Server local no causa ningún daño.

Ejecute el comando witadmin changefield . La sintaxis del comando es similar al ejemplo siguiente.

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

Para obtener más información sobre el comando witadmin changefield , vea Administrar campos de elementos de trabajo.

TF402556: para que el campo System.IterationId esté bien definido, debe asignarle el nombre Iteración id. y establecer su tipo en Integer.

Este error suele asociarse con plantillas de proceso obsoletas. Para solucionarlo, puede ejecutar el Asistente para configurar características para cada proyecto. Como alternativa, puede ejecutar el siguiente comando para automatizar el proceso.

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

TF402571: Falta el elemento BugWorkItems necesario en Configuración del proceso.

Este error se suele ver cuando un proceso no se actualizó durante algún tiempo. Para corregirlo, ejecute el Asistente para configurar características para cada proyecto.

TF402564: ha definido listas globales XX. Solo se permiten 64

Azure DevOps Services admite de forma nativa 64 listas globales. Este error suele surgir cuando hay un gran número de canalizaciones de compilación, ya que cada canalización nueva crea una lista global denominada Builds - TeamProjectName. Para resolver este error, quite las listas globales obsoletas.

Repetición de comprobaciones de validación

En cada iteración, solucione los errores y realice comprobaciones de validación para resolverlos, como se indica en los archivos de registro de validación. Persista con este ciclo hasta que se rectifiquen todos los errores y reciba la confirmación de que las comprobaciones de validación de recopilación se realizan correctamente.

Pasos siguientes

Preparación de la ejecución de pruebas