Información general sobre la migración
Pasar de Azure DevOps Server a Azure DevOps Services es un paso esencial para las organizaciones que desean aprovechar las ventajas de las características mejoradas, la escalabilidad y la colaboración basada en la nube. En esta introducción, se exploran las opciones para transferir los datos valiosos de Azure DevOps Server locales a Azure DevOps Services basados en la nube.
Para obtener información sobre las principales diferencias entre Azure DevOps Server local y Azure DevOps Services basado en la nube, consulte Comparación de Azure DevOps Services con Azure DevOps Server: Azure DevOps.
Independientemente de la opción de migración seleccionada, se recomienda determinar los recursos más importantes, como el código fuente y los elementos de trabajo. Debe pensar en el tamaño de los datos, la complejidad de la organización y asegurarse de que tiene suficiente tiempo para las ejecuciones de pruebas antes de la migración real para una transición fluida y correcta.
Enfoques para la migración
Es fundamental evaluar las ventajas y desventajas de cada enfoque para la migración, en función de sus motivaciones específicas para adoptar Azure DevOps Services. La estrategia correcta depende de su contexto y requisitos únicos.
| Opciones | Escenarios recomendados | Limitaciones |
|---|---|---|
| 1: Migración manual | Se usa para proyectos más pequeños o subconjuntos de datos específicos. | No todos los datos se pueden migrar con plena fidelidad y están sujetos a limitaciones. Esta migración no admite la migración de plantillas XML, por lo que debe volver a crear plantillas de proceso como plantillas heredadas. |
| 2: Herramienta de migración de datos de Azure DevOps | Se usa para migraciones a gran escala con diversos tipos de datos y estructuras complejas. | Solo puede "lift and shift" una colección de Azure DevOps Server a una nueva organización de Azure DevOps Services, sin modificaciones. Para más información, consulte la sección Limitaciones. |
| 3: Migración basada en API | Ofrece flexibilidad y personalización para las organizaciones con requisitos de migración únicos o necesidades de automatización. | Se pueden producir cambios de baja fidelidad, pérdida de datos e identificador. Para más información, consulte la sección Limitaciones. |
Opción 1: Migración manual
Por ejemplo, cuando el equipo de Azure DevOps de Microsoft eligió migrar de Azure DevOps Server a Azure DevOps Services, también decidimos pasar de Control de versiones de Team Foundation (TFVC) a Git. La migración requería una gran cantidad de planeamiento, pero cuando se migró, creamos un nuevo repositorio de Git mediante la versión de sugerencia de nuestros orígenes de TFVC y dejamos nuestro historial detrás en Azure DevOps Server. También hemos movido nuestros elementos de trabajo activos y hemos dejado atrás todos nuestros errores antiguos, los casos de usuario completados y las tareas, etc.
Proceso de migración manual
- Identifique los recursos más importantes que necesita migrar, normalmente código fuente, elementos de trabajo o ambos. Otros recursos de Azure DevOps Server: canalizaciones de compilación, planes de prueba, etc., son más difíciles de migrar manualmente.
- Identifique un tiempo adecuado para realizar la transición.
- Prepare las organizaciones de destino. Cree las organizaciones y los proyectos de equipo que necesita, aprovisione usuarios, etc.
- Migre los datos.
- Considere la posibilidad de hacer que las implementaciones de Azure DevOps Server de origen sean de solo lectura. Puede hacerlo de las siguientes maneras:
- Ajustar los permisos de nivel de proyecto: establezca los permisos de todos los usuarios o grupos en solo lectura en el nivel de proyecto, lo que puede hacer modificando los roles de seguridad en La configuración del proyecto.
- Modificar la configuración del repositorio: para cada repositorio, puede cambiar la configuración para que sean de solo lectura, lo que implica ajustar los permisos de cada usuario o grupo para permitir solo acciones de lectura.
- Uso de grupos de seguridad integrados: use los grupos de seguridad integrados para administrar los permisos de forma más eficaz. Puede asignar usuarios a grupos como "Lectores" para proporcionar acceso de solo lectura.
- Cambios en los permisos de scripting: si tiene muchos proyectos o repositorios, es posible que tenga que crear scripts. Puede usar la extensión DevOps de la CLI de Azure para enumerar todos los permisos y actualizarlos según sea necesario.
- Deshabilitar la característica de repositorio: deshabilita el acceso al repositorio, incluidas las compilaciones y las solicitudes de incorporación de cambios, pero mantiene el repositorio detectable con una advertencia. Vaya a Configuración del>proyecto Repositorios> del repositorio y, junto a Deshabilitar repositorio, mueva el botón de alternancia a Activado.
Opción 2: Herramienta de migración de datos de Azure DevOps
La herramienta de migración de datos de Azure DevOps es un conjunto de utilidades proporcionadas por Microsoft para facilitar la migración de datos de Azure DevOps Server a Azure DevOps Services. Estas herramientas ofrecen un enfoque simplificado para migrar varios artefactos, como código fuente, elementos de trabajo, casos de prueba y otros datos relacionados con el proyecto.
Antes de iniciar el proceso de migración, las herramientas pueden realizar un análisis previo a la migración para evaluar la preparación del entorno de origen e identificar posibles problemas o dependencias que podrían afectar a la migración. Evalúe la preparación, por lo que puede planear y mitigar los posibles desafíos de antemano.
Limitaciones de la herramienta de migración
La herramienta permite "lift and shift" una colección de servidores de Azure DevOps a una nueva organización del servicio Azure DevOps, sin modificaciones por los siguientes motivos:
- Integridad y coherencia de los datos:
- Al migrar datos, es fundamental mantener la integridad y la coherencia. Permitir modificaciones durante la migración podría provocar daños en los datos o incoherencias.
- La herramienta garantiza que los datos permanecen intactos durante el proceso de transferencia, lo que minimiza el riesgo de errores.
- Conservación de datos de origen:
- La herramienta de migración tiene como objetivo replicar fielmente los datos de origen en el entorno de destino.
- Las modificaciones podrían modificar los datos originales, lo que podría provocar discrepancias entre los datos migrados y los datos de origen.
- Comportamiento predecible:
- Al restringir las modificaciones, la herramienta garantiza un comportamiento predecible durante la migración.
- Los usuarios pueden confiar en resultados coherentes sin cambios inesperados.
- Enfoque de migración, no transformación:
- El propósito principal de la herramienta de migración es mover datos de una ubicación a otra.
- La transformación de datos (como modificar valores) normalmente se controla por separado después de la migración.
Puede purgar datos que no necesite antes o después de la migración.
Proceso de la herramienta de migración
- Complete los requisitos previos, como actualizar Azure DevOps Server a una de las dos versiones más recientes.
- Valide cada colección que quiera mover a Azure DevOps Services.
- Generar archivos de migración.
- Prepare todo para la ejecución de la migración.
- Realice una ejecución de prueba.
- Realice una migración.
- Confirme que los usuarios y los datos se han migrado y que la recopilación funciona según lo previsto.
Opción 3: Migración basada en API
Si por algún motivo no puede usar la herramienta de migración de datos, pero desea una migración de fidelidad más alta que la opción 2, puede elegir entre varias herramientas que usan API públicas para mover datos.
Limitaciones de migración basadas en API
Las limitaciones siguientes se producen con la migración basada en API:
- Migración de baja fidelidad:
- Limitación: las herramientas basadas en API proporcionan una mayor fidelidad que la copia manual, pero siguen siendo relativamente bajas.
- Implicación: aunque estas herramientas ofrecen cierta fidelidad, no conservan todos los aspectos de los datos.
- Ejemplo: Ninguno de ellos conserva las fechas originales de los conjuntos de cambios de TFVC (Control de versiones de Team Foundation).
- Muchos tampoco conservan las fechas modificadas de las revisiones de elementos de trabajo.
- Cambios de identificador y pérdida de datos:
- Limitación: durante la migración, las herramientas reproducen los cambios del elemento de trabajo, los conjuntos de cambios de TFVC, las fuentes de paquetes y los artefactos de canalización.
- Implicación: este proceso podría provocar la pérdida de datos, generar nuevos identificadores y modificar las fechas de creación, modificación y cierre.
- Ejemplo: El contexto histórico vinculado a fechas específicas podría perderse, lo que afecta a los informes y la rastreabilidad.
Proceso de migración basado en API
En general, solo se recomienda este enfoque si la fidelidad adicional más allá de una copia manual es fundamental. Si decide adoptar este enfoque, puede considerar la posibilidad de contratar a un consultor que tenga experiencia con una o varias de las herramientas y realizar una migración de prueba antes de la migración final.
Muchas organizaciones necesitan una migración de alta fidelidad solo para un subconjunto de su trabajo. El nuevo trabajo podría iniciarse directamente en Azure DevOps Services. Otro trabajo, con requisitos de fidelidad menos estrictos, podría migrarse mediante uno de los otros enfoques.
Modelos de proceso admitidos
Azure DevOps Services admite los siguientes modelos de proceso:
De forma predeterminada, el XML hospedado está desactivado en Azure DevOps Services. Activamos el modelo de proceso XML hospedado durante la migración solo si personalizaste un proyecto en Azure DevOps Server. Una vez que el proyecto esté en XML hospedado, puede actualizarlo a heredado después de la migración.
Principios fundamentales
Al migrar a Azure DevOps Services, tenga en cuenta los siguientes principios clave y limitaciones:
- Azure DevOps Services es solo en inglés: Azure DevOps Server admite varios idiomas, pero actualmente Azure DevOps Services solo admite inglés. Si la colección usa el idioma que no es inglés o usa un idioma que no es inglés en el pasado y ha convertido el idioma en inglés durante una actualización, no puede usar la herramienta de migración de datos.
- Herencia: un proyecto, que se creó a partir de la plantilla de proceso Agile, Scrum o CMMI y que nunca se personalizó, se encuentra en el modelo de proceso de herencia después de la migración.
- XML hospedado: cualquier proyecto con personalizaciones usa el modelo de proceso XML hospedado.
- Proceso por proyecto personalizado: aunque Azure DevOps Services permite que los proyectos compartan un proceso, la Herramienta de migración de datos crea un proceso XML hospedado para cada proyecto de equipo personalizado. Por ejemplo, si tiene 30 proyectos personalizados, tiene 30 procesos XML hospedados para administrar. Si desea personalizar aún más el proceso XML hospedado para todos los proyectos, debe actualizar cada proceso XML hospedado por separado.
- Validación de procesos: la validación de procesos de la Herramienta de migración de datos detecta el modelo de proceso de destino para cada proyecto. Para poder migrar, debe corregir los errores de validación de procesos para los proyectos XML hospedados. Es posible que quiera considerar la posibilidad de actualizar el proceso de los proyectos para que coincida con uno de nuestros procesos (Agile, Scrum o CMMI) para aprovechar el modelo de proceso de herencia. Obtenga más información sobre los tipos de validación de procesos en nuestra documentación.
Recursos
- Notificar un problema en la Comunidad de desarrolladores
- Obtener soporte técnico y proporcionar comentarios