Introducción a una migración de Bitbucket Server 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 realizar la migración desde Bitbucket Server, puedes usar esta guía para planear e implementar la migración, y completar tareas de seguimiento.

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.

• 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 realizar el inventario de los repositorios que necesitas migrar, puede ponderar 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. Determina cuántos repositorios y solicitudes de incorporación de cambios necesitas migrar.
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 Bitbucket Server, GitHub Enterprise Importer solo migra repositorios de Git y solicitudes de incorporación de cambios. Cualquier otro recurso, como las canalizaciones de CI, permanecerá en Bitbucket Server.

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

1. Revisa los datos que se migran desde Bitbucket Server. Para obtener más información, vea «Información sobre migraciones de Bitbucket Server 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 en GitHub, o bien un propietario de la organización debe concederte el rol de migración.

También debes tener los permisos necesarios y el acceso a la instancia de Bitbucket Server:

• Permisos de administrador o superadministrador
• Si la instancia de Bitbucket Server se ejecuta en Linux, el acceso SFTP a la instancia se efectúa mediante una clave privada SSH compatible (consulta "Administración del acceso para una migración desde Bitbucket Server")
• Si la instancia de Bitbucket Server se ejecuta en Windows, acceso compartido de archivos (SMB) a la instancia

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 Bitbucket Server." % 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 Bitbucket Server".
4. Confirma que el responsable de la migración tiene permisos de administrador o superadministrador, y acceso SFTP para la instancia de Bitbucket Server.

¿Qué estructura organizativa se quiere en GitHub?

A continuación, planifica la estructura organizativa que crearás en GitHub.

En Bitbucket Server, los repositorios se agrupan en proyectos. En GitHub, los repositorios son propiedad de las organizaciones. Pero no debes suponer que el mejor enfoque es crear una organización en GitHub por cada proyecto en Bitbucket Server.

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 repositorio migrado será propiedad de una de estas organizaciones, lo que 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 en GitHub. Para obtener más información, vea «Acerca de los equipos».

Si quieres dividir el esfuerzo de migración en lotes, considera la posibilidad de realizar lotes por organización.

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 Bitbucket Server".
7. Ejecuta las migraciones de producción. Para obtener más información, vea «Migración de repositorios desde Bitbucket Server 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 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.

• 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 Bitbucket Server, GitHub Enterprise Importer no intenta migrar permisos de repositorio desde Bitbucket Server.

Para conceder acceso a los repositorios migrados, puedes crear equipos y conceder a cada equipo acceso al repositorio.

1. Crea equipos. Para obtener más información, vea «Crear un equipo».
2. Agrega miembros de la organización a equipos. Para obtener más información, vea «Agregar miembros de la organización a un equipo».
3. Concede a cada equipo acceso al repositorio. Para obtener más información, consulta "Administrar el acceso de equipo a un repositorio de la organización".

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 obtener más información, consulta "Administración del acceso para una migración desde Bitbucket Server".