Introducción a una migración desde Azure DevOps a GitHub Enterprise Cloud

Información general

Con GitHub Enterprise Importer, puedes realizar la migración a GitHub Enterprise Cloud por repositorios individuales. Para más información, consulta Acerca de GitHub Enterprise Importer.

Si vas a migrar desde Azure DevOps (ADO), puedes usar esta guía para planificar e implementar la migración, y completar tareas de seguimiento.

Las empresas que migran desde ADO a GitHub suelen seguir un enfoque de varias fases.

1. Migrar repositorios de ADO a GitHub.
2. Migrar canalizaciones de Azure Pipelines a GitHub Actions.
3. Migrar los recursos restantes, como paneles y artefactos, de ADO a GitHub.

Esta guía te guiará por la finalización de la primera fase, la migración de repositorios a GitHub, y asume que usas la ADO2GH extension of the GitHub CLI.

Planificación de la migración

Para planear la migración, hazte las siguientes preguntas.

• ¿En qué momento es necesario completar la migración?
• ¿Se sabe qué se va a migrar?
• ¿Quién ejecutará la migración?
• ¿Qué estructura organizativa se quiere en GitHub?

¿En qué momento es necesario completar la migración?

Determina la escala de tiempo, que en gran medida determinará el enfoque. El primer paso para determinar la escala de tiempo consiste en obtener un inventario de lo que necesitas migrar. Para recopilar estos datos, usa la gh-repo-stats extensión para GitHub CLI. Esta herramienta de código abierto genera un informe que detalla la cantidad de datos que hay que migrar para una organización.

• Número de repositorios
• Número de solicitudes de incorporación de cambios

El tiempo de migración se basa en gran medida en el número de solicitudes de incorporación de cambios en un repositorio. Si quieres migrar 1000 repositorios y cada uno tiene 100 solicitudes de incorporación de cambios de media y solo 50 usuarios han contribuido a los repositorios, es probable que la migración sea muy rápida. Si solo quieres migrar 100 repositorios, pero cada uno tiene 75 000 solicitudes de incorporación de cambios de media y 5 000 usuarios, la migración tardará mucho más y necesitará mucha más planificación y pruebas.

Después de usar el analizador, puedes pesar los datos de inventario en la escala de tiempo deseada. Si la organización puede soportar un mayor grado de cambio, es posible que puedas migrar todos los repositorios a la vez, y completar los esfuerzos de migración en unos días. Pero es posible que tengas varios equipos que no se puedan migrar al mismo tiempo. En este caso, es posible que quieras procesar por lotes y escalonar las migraciones para ajustarse a las escalas de tiempo de los equipos, lo que amplía el esfuerzo de migración.

1. Usa la gh-repo-stats extensión para los GitHub CLI y luego revisa el inventario de migración.
2. Para comprender cuándo los equipos pueden estar listos para la migración, entrevista a las partes interesadas.
3. Revisa todo el resto de esta guía y, después, decide una escala de tiempo de migración.

¿Se sabe qué se va a migrar?

Asegúrate de que tú y las partes interesadas entendéis qué datos se pueden migrar mediante GitHub Enterprise Importer.

En el caso de las migraciones desde ADO, GitHub Enterprise Importer solo migra repositorios de Git, incluidas las solicitudes de incorporación de cambios y algunas directivas de rama. Cualquier otro recurso, como canalizaciones, elementos de trabajo, artefactos, planes de prueba, versiones y paneles, permanecerá en ADO.

Como los permisos funcionan de forma diferente en GitHub que en ADO, GitHub Enterprise Importer no intenta migrar permisos de repositorio desde ADO. Para más información, consulta Configuración de permisos.

Los enlaces de servicio no se migran desde ADO, por lo que tendrás que volver a crearlos por separado.

1. Revisa los datos que se migran desde Azure DevOps. Para más información, consulta Información sobre migraciones desde Azure DevOps a GitHub Enterprise Cloud.
2. Haz una lista de los datos que necesitarás migrar o volver a crear manualmente.

¿Quién ejecutará la migración?

Para migrar un repositorio, debes ser propietario de la organización de destino, o bien un propietario de la organización debe concederte el rol de migración.

1. Decide si quieres que un propietario de la organización de destino realice las migraciones, o bien si necesitas conceder el rol de migración a otra persona.
2. Si decides conceder el rol de migración, decide a qué persona o equipo vas a conceder el rol.
3. Concede el rol de migración a la persona o al equipo. Para obtener más información, consulta Administración del acceso para una migración desde Azure DevOps. % data reusables.enterprise-migration-tool.confirm-migrator-has-correct-pats %} Para obtener más información, consulta Administración del acceso para una migración desde Azure DevOps.

¿Qué estructura organizativa se quiere en GitHub?

A continuación, planifica la estructura organizativa que crearás en GitHub. ADO y GitHub tienen diferentes formas de organizar el trabajo de una empresa.

• ADO: Organización > proyectos de equipo > repositorios
• GitHub: Empresa > organización > repositorios

Después de realizar la migración a GitHub, solo debes tener una cuenta empresarial y un número reducido de organizaciones propiedad de esa empresa. Cada organización de ADO se debe corresponder a una sola organización en GitHub. No se recomienda crear una organización en GitHub para cada proyecto de equipo en ADO.

Esto puede dar lugar a una gran lista de repositorios no agrupados dentro de cada organización. Pero puedes administrar el acceso a grupos de repositorios mediante la creación de equipos. Para más información, consulta Acerca de los equipos.

Si quieres dividir el esfuerzo de migración en lotes, la nueva estructura puede ayudarte a determinar los lotes. Si tienes más de una organización en ADO y los repositorios de cada organización tienen un tamaño razonable, considera la posibilidad de procesar por lotes por organización. Puedes usar la GitHub CLI a fin de generar un script de migración para toda una organización en ADO.

1. Decide cuál será la nueva organización estructural.
2. Decida si necesitas dividir el esfuerzo de migración en lotes más pequeños.
3. Si es así, decide cómo quieres dividir las migraciones.

Ejecución de las migraciones

Una vez que completes la planificación, puedes iniciar las migraciones reales. Para ayudar a descubrir problemas que podrían ser únicos para la empresa durante y después de la migración, se recomienda encarecidamente realizar ejecuciones de prueba de todas las migraciones. Después de resolver las incidencias detectadas por las ejecuciones de prueba, puedes ejecutar las migraciones de producción.

Las migraciones de prueba ayudan a determinar varios fragmentos críticos de información.

• Si la migración de un repositorio determinado se puede completar correctamente
• Si puedes devolver al repositorio a un estado en el que los usuarios puedan empezar a trabajar correctamente
• Cuánto tiempo tardará una migración en ejecutarse, lo que resulta útil para planear las programaciones de migración y establecer las expectativas de las partes interesadas

Las ejecuciones de prueba no necesitan mucha coordinación del tiempo. GitHub Enterprise Importer nunca necesita tiempo de inactividad para los usuarios de un repositorio que se va a migrar. Pero se recomienda detener el trabajo durante las migraciones de producción para asegurarse de que no se creen datos durante la migración, que después faltarían en el repositorio migrado. Esto no es un problema para las migraciones de prueba, por lo que las ejecuciones de prueba se pueden realizar en cualquier momento. A fin de reducir el tiempo necesario para completar las migraciones de prueba, puedes programar los lotes de las ejecuciones de prueba de manera consecutiva. Después, los usuarios de esos repositorios pueden validar los resultados por su cuenta.

Se recomienda crear una organización de prueba para usarla como destino para las migraciones de prueba. Puedes usar una sola organización para todas las ejecuciones de prueba, o bien puedes crear una organización de prueba para cada organización de destino prevista. Considera la posibilidad de incluir -sandbox al final de los nombres de la organización, para aclarar que las organizaciones solo están pensadas para la validación de la migración y no para producción. Puedes eliminar las organizaciones de prueba cuando hayas terminado.

1. Crea una organización de prueba para las migraciones de prueba.
2. Ejecuta las migraciones de prueba.
3. Completa las tareas de seguimiento que se describen a continuación para las migraciones de prueba.
4. Pide a los usuarios que validen los resultados de las migraciones.
5. Resuelve las incidencias detectadas por las migraciones de prueba.
6. Si el destino usa listas de direcciones IP permitidas, configura la lista para permitir el acceso por parte de GitHub Enterprise Importer. Para obtener más información, consulta Administración del acceso para una migración desde Azure DevOps.
7. Ejecuta las migraciones de producción. Para más información, consulta Migración de repositorios desde Azure DevOps a GitHub Enterprise Cloud.
8. Opcionalmente, elimina la organización de prueba.

Realización de tareas de seguimiento

Después de que finalice cada migración, tendrás que completar algunas tareas adicionales antes de que el repositorio esté listo para funcionar.

• Comprobación del estado de la migración
• Revisión del registro de migración
• Configurar la visibilidad de un repositorio
• Configuración de permisos
• Reclamación de maniquíes
• Configuración de listas de direcciones IP permitidas

Comprobación del estado de la migración

En primer lugar, compruebe si la migración se realizó correctamente o si fue errónea.

La forma de comprobar el estado de la migración depende de cómo ejecutó la migración.

• Si ejecutó la migración con GitHub CLI, de manera predeterminada, el proceso mostrará si la migración se realizó correctamente o si fue errónea una vez completada la migración. Si la migración fue errónea, se le indicará el motivo para la ejecución errónea.

  Migration completed (ID: RM_123)! State: SUCCEEDED
  

• Si ejecutó la migración con GitHub CLI con el argumento --queue-only opcional, el proceso se cerrará inmediatamente después de poner en cola la migración y no se le indicará si la migración se realizó correctamente o si fue errónea. Puede comprobar el estado de una migración mediante el comando wait-for-migration o revisando el registro de migración.

• Si ejecutó la migración mediante la API de GraphQL, puede consultar los campos state y failureReason en el objeto RepositoryMigration.

Si se la migración fue errónea, el registro de migración puede contener información adicional sobre la causa del error. Para más información, véase Revisión del registro de migración.

Revisión del registro de migración

En primer lugar, revise el registro de migración para cada repositorio migrado. Para obtener más información, vea «Acceso a los registros de migración para GitHub Enterprise Importer».

Si se la migración fue errónea, el registro puede contener información adicional sobre la causa del error.

Si la migración se realizó correctamente, puede haber advertencias en el registro de migración que representan fragmentos específicos de datos (por ejemplo, solicitudes de cambios, problemas o comentarios) que no se migraron o se migraron con notas de precaución.

Para obtener más información sobre cómo reconocer las advertencias de migración, véase "Solución de problemas de la migración con GitHub Enterprise Importer". Después de revisar las advertencias de migración, deberá tomar una decisión sobre si puede aceptar esas advertencias y avanzar.

Configurar la visibilidad de un repositorio

Todos los repositorios se migran como privados de manera predeterminada y solo el usuario que ha ejecutado la migración y los propietarios de la organización tendrán acceso al repositorio. Si no quieres que el repositorio sea privado, cambia la visibilidad.

• Puede establecer la visibilidad de un repositorio con la opción --target-repo-visibility de la CLI o la propiedad targetRepoVisibility de GraphQL.
• Puedes cambiar la visibilidad de un repositorio en el explorador. Para obtener más información, vea «Configurar la visibilidad de un repositorio».
• Como alternativa, puedes usar GitHub CLI para cambiar la visibilidad del repositorio desde la línea de comandos. Incluso puedse agregar este comando al script que se ha generado para ejecutar las migraciones. Para más información, vea gh repo edit en la documentación de GitHub CLI.

Configuración de permisos

Como los permisos funcionan de forma diferente en GitHub que en ADO, GitHub Enterprise Importer no intenta migrar permisos de repositorio desde ADO.

Si has usado la CLI de ADO2GH, GitHub Enterprise Importer creará dos equipos en GitHub para cada proyecto de equipo de ADO. A cada equipo se le concede un nivel de acceso diferente a todos los repositorios que se han originado en el proyecto de equipo.

Team	Acceso a los repositorios migrados
TEAM-PROJECT: Mantenedores	Responsable de mantenimiento
TEAM-PROJECT: Administradores	Administración

Para conceder acceso a los repositorios migrados, puedes agregar personas a estos equipos. Puedes hacerlo manualmente en GitHub, o si decides vincular los equipos a grupos de Azure Active Directory (AAD) durante la migración, mediante la administración de la pertenencia a grupos en AAD. Para más información sobre cómo administrar manualmente la pertenencia a equipos, consulta Agregar miembros de la organización a un equipo.

Si no usas la CLI de ADO2GH, o bien si necesitas una configuración de permisos más avanzada que la predeterminada, configura los permisos para los repositorios migrados. Puedes modificar el script de migración para adaptarlo a tus necesidades, o bien configurar manualmente los permisos después de la migración. Para más información sobre cómo administrar el acceso a los repositorios en GitHub, consulta Roles de repositorio para una organización.

1. Decide qué estructura de permisos necesitas en GitHub.
2. Si es diferente de la predeterminada, elabora un plan para configurar la pertenencia a equipos y permisos.

Reclamación de maniquíes

Después de ejecutar una migración con GitHub Enterprise Importer, toda la actividad del usuario en el repositorio migrado (excepto las confirmaciones de Git) se atribuye a identidades de marcador de posición denominadas maniquíes.

Puedes reasignar el historial de cada maniquí a un miembro de la organización con la GitHub CLI o en el explorador. Si usas la datos GitHub CLI, puedes reclamar maniquíes de forma masiva. Para más información, consulta "Reclamación de maniquíes para GitHub Enterprise Importer".

1. Decide si quieres reclamar maniquíes.
2. Planifica cuándo completarás las reclamaciones.
3. Reclama los maniquíes.
4. Si alguno de los miembros aún no tiene el acceso adecuado al repositorio por medio de la pertenencia al equipo, concede a los miembros acceso al repositorio. Para obtener más información, vea «Administrar el acceso de una persona a un repositorio de una organización».

Configuración de listas de direcciones IP permitidas

Si has agregado los intervalos IP para GitHub Enterprise Importer a la lista de direcciones IP permitidas para la organización de destino, puedes quitar esas entradas. Si has deshabilitado las restricciones de lista de direcciones IP permitidas del proveedor de identidades para la empresa de destino, ahora puedes volver a habilitarlas.

Para más información, consulta Administración del acceso para una migración desde Azure DevOps.