Migración de datos a GitHub Enterprise Server

Preparación de los datos migrados

1. Usando el comando, copie el archivo de migración generado desde su instancia de origen o organización a su destino de GitHub Enterprise Server:

   scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/
   

2. Acceda mediante SSH a la instancia de GitHub Enterprise Server de destino. Para más información, consulta Acceder al shell administrativo (SSH).

   ssh -p 122 admin@HOSTNAME
   

3. Asegúrate de que el archivo de migración tiene suficientes permisos de lectura.

   chmod 644 /home/admin/MIGRATION-GUID.tar.gz
   

4. Usa el comando a fin de preparar el archivo para importar en la instancia de destino y generar un nuevo GUID de migración para usarlo en los pasos siguientes:

   ghe-migrator prepare /home/admin/MIGRATION-GUID.tar.gz
   

   • Para comenzar un nuevo intento de importación, vuelva a ejecutar y obtenga un GUID de migración nuevo.
   • Para especificar dónde se deben almacenar provisionalmente los archivos de migración, anexe --staging-path=/full/staging/path al comando. Tiene como valor predeterminado /data/user/tmp.

Generar una lista de conflictos de migración

1. Mediante el comando con el GUID de migración, genere un archivo conflicts.csv:

   ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv
   

   • Si no se notifica ningún conflicto, puede importar los datos de forma segura.

2. Si hay conflictos, con el comando , copie conflicts.csv en el equipo local:

   scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop
   

3. Continúe con Resolución de conflictos de migración o configuración de asignaciones personalizadas.

Revisar conflictos de migración

1. Abra conflicts.csv con un editor de texto o un software de hoja de cálculo compatible con CSV.
2. Con las instrucciones de los ejemplos y las tablas de referencia siguientes, revise el archivo conflicts.csv para asegurarse de que al realizar la importación se tomarán las medidas adecuadas.

El archivo conflicts.csv contiene un mapa de migración de conflictos y acciones recomendadas. Un mapa de migración enumera tanto los datos que se migran desde el origen como la forma en que los datos se aplicarán al destino.

model_name	source_url	target_url	recommended_action
user	https://example-gh.source/octocat	https://example-gh.target/octocat	map
organization	https://example-gh.source/octo-org	https://example-gh.target/octo-org	map
repository	https://example-gh.source/octo-org/widgets	https://example-gh.target/octo-org/widgets	rename
team	https://example-gh.source/orgs/octo-org/teams/admins	https://example-gh.target/orgs/octo-org/teams/admins	merge
project	https://example-gh.source/octo-org/widgets/projects/1	https://example-gh.target/octo-org/projects/1	merge

Cada fila de conflicts.csv proporciona la información siguiente:

Nombre	Descripción
model_name	El tipo de datos que están siendo modificados.
source_url	La URL fuente de los datos.
target_url	La URL de destino esperada de los datos.
recommended_action	La acción preferida se realizará al importar los datos.

Posibles mapeos para cada tipo de registro

Hay varias acciones de mapeo de datos diferentes que puede realizar al transferir datos.

action	Descripción	Modelos aplicables
import	(predeterminado) Los datos del origen se importan al destino.	Todos los tipos de registro
map	En lugar de crear un modelo basado en los datos de origen, se usa un registro existente en el destino. Resulta útil para importar repositorios en una organización existente o asignar identidades de usuario que están en el destino a identidades de usuario que están en el origen.	Usuarios, organizaciones, proyectos
rename	Los datos del origen se renombran y luego se copian en el destino.	Usuarios, organizaciones, repositorios, proyectos
map_or_rename	Si el destino existe, asignar a ese destino. De lo contrario, renombrar el modelo importado.	Usuarios
merge	Los datos del origen se combinan con los datos existentes en el destino.	Equipos, proyectos

Se recomienda encarecidamente que revise el archivo conflicts.csv y use para asegurarse de que se realizan las acciones adecuadas. Si todo parece estar bien, puede continuar.

Resolver conflictos de migración o crear asignaciones personalizadas

Si cree que realizará un cambio incorrecto, puede hacer correcciones y cambiar los datos en conflicts.csv. Puede realizar cambios en cualquiera de las filas de conflicts.csv.

Por ejemplo, imagine que observa que el usuario del origen se asigna a en el destino.

model_name	source_url	target_url	recommended_action
user	https://example-gh.source/octocat	https://example-gh.target/octocat	map

Puedes optar por asignar el usuario a un usuario diferente en el destino. Imagine que sabe que realmente debería ser en el destino. Puede cambiar la columna de conflicts.csv para que haga referencia a .

model_name	source_url	target_url	recommended_action
user	https://example-gh.source/octocat	https://example-gh.target/monalisa	map

Como otro ejemplo, si quiere cambiar el nombre del repositorio a en la instancia de destino, cambie a y a .

model_name	source_url	target_url	recommended_action
repository	https://example-gh.source/octo-org/widgets	https://example-gh.target/octo-org/amazing-widgets	rename

Añadir mapeos personalizados

Una situación común durante una migración es que los usuarios migrados tengan diferentes nombres de usuario en el destino que los que tienen en el origen.

Dada una lista de nombres de usuario en el origen y una lista de nombres de usuario en el destino, puedes crear un archivo CSV con asignaciones personalizadas y luego aplicarlo para garantizar que el nombre de usuario y el contenido de cada usuario se atribuyan correctamente al final de la migración.

Puede generar rápidamente un archivo CSV con los usuarios que están siendo migrados, en el formato CSV necesario para aplicar asignaciones personalizadas, mediante el comando:

ghe-migrator audit -m user -g MIGRATION-GUID > users.csv

Ahora, puede editar ese CSV y escribir la nueva URL para cada usuario que le gustaría asignar o renombrar, y luego actualizar la cuarta columna para tener o según corresponda.

Por ejemplo, para cambiar el nombre del usuario por en el elemento de destino, tendría que crear una fila con el siguiente contenido:

model_name	source_url	target_url	state
user	https://example-gh.source/octocat	https://example-gh.target/monalisa	rename

Se puede usar el mismo proceso para crear asignaciones para cada registro que admita asignaciones personalizadas. Para más información, vea nuestra tabla sobre las posibles asignaciones de registros.

Aplicar datos de migración modificados

1. Después de realizar cambios, use el comando para aplicar el archivo conflicts.csv modificado (o cualquier otro archivo .csv de asignación en el formato correcto) a la instancia de destino:

   scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/
   

2. Vuelva a asignar los datos de migración con el comando , y pase la ruta al archivo .csv modificado y al GUID de migración:

   ghe-migrator map -i conflicts.csv -g MIGRATION-GUID
   

3. Si el comando notifica que sigue habiendo conflictos, vuelva a ejecutar el proceso de resolución de conflictos de migración.

Aplicar los datos importados en GitHub Enterprise Server

1. Acceda mediante SSH a la instancia de GitHub Enterprise Server de destino. Para más información, consulta Acceder al shell administrativo (SSH).

   ssh -p 122 admin@HOSTNAME
   

2. Con el comando , inicie el proceso de importación. Necesitará:

   • El GUID de migración. Para más información, consulta Preparación de los datos migrados para su importación a GitHub Enterprise Server.
   • personal access token para la autenticación. personal access token que usa son solo para la autenticación como administrador del sitio y no requieren ningún ámbito específico ni permisos. Para más información, consulta AUTOTITLE.

   $ ghe-migrator import /home/admin/MIGRATION-GUID.tar.gz -g MIGRATION-GUID -u USERNAME -p TOKEN
   
   > Starting GitHub::Migrator
   > Import 100% complete /
   

   • Para especificar dónde se deben almacenar provisionalmente los archivos de migración, anexe --staging-path=/full/staging/path al comando. Tiene como valor predeterminado /data/user/tmp.

Revisar datos de migración

De forma predeterminada, devuelve todos los registros. También te permite filtrar los registros por:

• Los tipos de registros.
• El estado de los registros.

Los tipos de registro coinciden con los encontrados en los datos migrados.

Filtros de tipo de registro

Tipo de registro	Nombre de filtro
Usuarios	user
Las organizaciones	organization
Repositorios	repository
Teams	team
Hitos	milestone
Proyectos (clásico)	project
Problemas	issue
Comentarios de propuestas	issue_comment
Solicitudes de incorporación de cambios	pull_request
Revisiones de solicitudes de extracción	pull_request_review
Comentarios sobre confirmación de cambios	commit_comment
Comentarios sobre revisiones de solicitudes de extracción	pull_request_review_comment
Lanzamientos	release
Medidas adoptadas en las solicitudes de extracción o propuestas	issue_event
Ramas protegidas	protected_branch

Filtros de estado de registro

Estado del registro	Descripción
export	El registro se exportará.
import	El registro se importará.
map	El registro será mapeado.
rename	El registro se renombrará.
merge	El registro se fusionará.
exported	El registro se exportó con éxito.
imported	El registro se importó con éxito.
mapped	El registro se asignó con éxito.
renamed	El registro se renombró con éxito.
merged	El registro fue fusionado exitosamente.
failed_export	El registro no se pudo exportar.
failed_import	El registro no se pudo importar.
failed_map	El registro no se pudo mapear.
failed_rename	El registro no se pudo renombrar.
failed_merge	El registro no se pudo fusionar.

Filtrar registros auditados

Con el comando , puede filtrar según el tipo de registro mediante la marca . Del mismo modo, puede filtrar por el estado de importación mediante la marca . El comando tiene este aspecto:

ghe-migrator audit -m RECORD_TYPE -s STATE -g MIGRATION-GUID

Por ejemplo, para ver cada organización y equipo importados con éxito, debes ingresar:

$ ghe-migrator audit -m organization,team -s mapped,renamed -g MIGRATION-GUID
> model_name,source_url,target_url,state
> organization,https://gh.source/octo-org/,https://ghe.target/octo-org/,renamed

Se recomienda encarecidamente auditar cada importación que falló. Para hacerlo, introducirá lo siguiente:

$ ghe-migrator audit -s failed_import,failed_map,failed_rename,failed_merge -g MIGRATION-GUID
> model_name,source_url,target_url,state
> user,https://gh.source/octocat,https://gh.target/octocat,failed
> repository,https://gh.source/octo-org/octo-project,https://ghe.target/octo-org/octo-project,failed

Si tienes alguna duda sobre las importaciones fallidas, puedes ponerte en contacto con nosotros en Soporte técnico para GitHub Enterprise.

Completar la importación en GitHub Enterprise Server

Después de que se aplique tu migración a tu instancia destino y la hayas revisado, desbloquearás los repositorios y los borrarás del origen. Antes de eliminar los datos de origen, se recomienda esperar alrededor de dos semanas para asegurarse de que todo funciona de acuerdo con lo esperado.

Desbloquear repositorios en la instancia de destino

1. SSH en tu instancia de GitHub Enterprise Server Si la instancia consta de varios nodos, por ejemplo, si la alta disponibilidad o la replicación geográfica están configuradas, utiliza SSH en el nodo principal. Si usas un clúster, puedes utilizar SSH en cualquier nodo. Reemplace HOSTNAME por el nombre de host de la instancia, o el nombre de host o la dirección IP de un nodo. Para más información, consulta Acceder al shell administrativo (SSH).

   Shell

   ssh -p 122 admin@HOSTNAME
   

2. Desbloquee todos los repositorios importados con el comando ghe-migrator unlock. Nececitarás tu GUID de Migración:

$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project

Desbloquear repositorios en el origen

Una vez completada la migración, debe desbloquear los repositorios en el origen.

Desbloquear los repositorios de una organización en GitHub.com

Para desbloquear los repositorios en una organización de GitHub.com, enviará una solicitud al punto de conexión de desbloqueo de migración. Necesitará:

• Tu token de acceso para autenticación
• El aspecto único de la migración
• El nombre del repositorio a desbloquear

curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  -H "Accept: application/vnd.github.wyandotte-preview+json" \
  https://api.github.com/orgs/ORG-NAME/migrations/ID/repos/REPO_NAME/lock

Borrar los repositorios de una organización en GitHub.com

Después de desbloquear los repositorios de la organización de GitHub.com, tendrá que borrar todos los repositorios que haya migrado antes mediante el punto de conexión de eliminación de repositorios. Necesitarás tu token de acceso para la autenticación:

curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  https://api.github.com/repos/ORG-NAME/REPO_NAME

Desbloquear repositorios desde una instancia de GitHub Enterprise Server

1. SSH en tu instancia de GitHub Enterprise Server Si la instancia consta de varios nodos, por ejemplo, si la alta disponibilidad o la replicación geográfica están configuradas, utiliza SSH en el nodo principal. Si usas un clúster, puedes utilizar SSH en cualquier nodo. Reemplace HOSTNAME por el nombre de host de la instancia, o el nombre de host o la dirección IP de un nodo. Para más información, consulta Acceder al shell administrativo (SSH).

   Shell

   ssh -p 122 admin@HOSTNAME
   

2. Desbloquee todos los repositorios importados con el comando ghe-migrator unlock. Nececitarás tu GUID de Migración:

$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project