Migración del repositorio con Enterprise Live Migrations

Prerequisites

Asegúrese de que está listo para la migración. Consulte Preparación para la migración en vivo desde GitHub Enterprise Server a GHE.com.

1. Creación de tokens de acceso

Debe autenticarse con un personal access token (classic) tanto para el origen como para el destino de la migración. Para obtener instrucciones detalladas, consulte Administración de tokens de acceso personal.

          **Tome nota de ambos tokens**, ya que los necesitará en el paso siguiente.

1. Cree un personal access token (classic) en GitHub Enterprise Server con los siguientes alcances.

   • repo
   • admin:org
   • admin:repo_hook
   • admin:org_hook

2. Cree un personal access token (classic) en GHE.com con los siguientes ámbitos.

   • repo
   • workflow
   • admin:org
   • admin:repo_hook
   • admin:enterprise

3. Si se ha establecido el inicio de sesión único en la organización de destino en GHE.com, autorice el token de GHE.com.

2. Configurar GitHub Enterprise Server

Debe establecer alguna configuración en la GitHub Enterprise Server instancia antes de realizar una migración. Estos valores de configuración se aplican a todas las ELM migraciones. GitHub Enterprise Server Los desarrolladores pueden experimentar un breve tiempo de inactividad al aplicar la nueva configuración.

1. Acceda al GitHub Enterprise Server shell administrativo mediante SSH. Consulte Acceder al shell administrativo (SSH).

2. Establezca las siguientes variables de configuración con ghe-config.

   Por ejemplo: ghe-config app.elm-exporter.enabled true

   Variable	Establézcalo en...
   app.elm-exporter.enabled	true
   app.elm.internal-webhooks-enabled	true
   app.elm-exporter.webhooks-loopback-address-enabled	true
   secrets.elm-exporter.migration-target-url	La dirección URL de API de la empresa de destino (por ejemplo: https://api.octocorp.ghe.com).

          **No** incluya una barra diagonal final al final de la dirección URL. |
   

   | secrets.elm-exporter.migration-target-token | El token de acceso que has creado para GHE.com. | | secrets.elm-exporter.source-token | El token de acceso que creó para GitHub Enterprise Server. | | secrets.elm-exporter.source-user | Nombre de usuario asociado al GitHub Enterprise Server token (por ejemplo: ghe-admin). |

3. Si aún no tiene las migraciones habilitadas y el almacenamiento de blobs configurados en la instancia, puede configurarlas ahora. Puede comprobar la configuración existente en la sección "Migraciones" de la Consola de administración (HOSTNAME/setup/settings).

   Puede usar los siguientes valores predeterminados, que no introducirán ninguna funcionalidad inesperada.

   Shell

   ghe-config app.migrations.enabled true
   

   Shell

   ghe-config secrets.migrations.blob-storage-type local-storage
   

4. Aplique la configuración.

   Shell

   ghe-config-apply
   

3. Establecer variables de entorno necesarias

Cuando se haya aplicado la configuración y antes de iniciar una migración, establezca las variables de entorno necesarias. Por ejemplo:

export API_URL='http://localhost:1738'

          **No** incluya una barra diagonal final al final de la dirección URL. |

| MIGRATION_TARGET_TOKEN | personal access token (classic) para GHE.com |

Cualquiera de estos valores también se puede proporcionar como marcas de la CLI en cualquier elm comando, que tendrá prioridad sobre las variables. Por ejemplo: --api-url http://localhost:1738.

4. Crea una migración

Cree una nueva migración especificando los detalles del repositorio de origen y de destino. --pat-name debe establecerse como system-pat un valor estático. Los demás valores son marcadores de posición específicos de su entorno.

elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO \
  --target-api GHEC-API-URL \
  --pat-name system-pat

elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO \
  --target-api GHEC-API-URL \
  --pat-name system-pat

Por ejemplo:

elm migration create \
  --source-org my-ghes-org \
  --source-repo my-ghes-repo \
  --target-org my-dr-org \
  --target-repo my-dr-repo \
  --target-api $MIGRATION_TARGET_URL \
  --pat-name system-pat

Marcas opcionales:

• --start: si está listo para iniciar la migración de inmediato.
• --target-visibility: los repositorios migrados se crean con visibilidad interna de forma predeterminada, pero puede especificar private.

Guardar el identificador de migración

Debería ver una respuesta similar a la siguiente:

{
  "migrationId": "2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9",
  "expiresAt": "2026-02-11T21:49:33.619162159Z"
}

Exporte como migrationId una variable, ya que la necesitará para los siguientes comandos. Por ejemplo:

export MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9'

5. Iniciar la migración

Si aún no inició la migración, iníciela ahora con el identificador de migración que acaba de guardar.

elm migration start --migration-id $MIGRATION_ID

elm migration start --migration-id $MIGRATION_ID

Esto inicia los procesos de reposición y actualización dinámica. ELM está recopilando ahora datos del repositorio de origen y escuchando los eventos de webhook que se admiten.

6. Supervisión de la migración

Cuando se haya iniciado la migración, debería ver un nuevo repositorio en GHE.com. Durante la migración, verá que el repositorio se rellena con una carga inicial de datos y recibe actualizaciones a medida que los desarrolladores siguen trabajando en el repositorio de origen.

Ejecute el siguiente comando periódicamente para supervisar el estado de la migración. Verá un desglose de los estados del origen y el destino e información sobre los datos activos que se van a migrar.

elm migration status --migration-id $MIGRATION_ID

elm migration status --migration-id $MIGRATION_ID

El indicador más importante de la respuesta es el estado del objeto combinedState . Cuando el estado alcance COMBINED_STATUS_READY_FOR_CUTOVER, debe estar listo para continuar con el paso siguiente. Sin embargo, se le avisará en displayMessage si algún recurso individual no se pudo migrar, lo que puede que tenga que investigar.

Por ejemplo:

  "combinedState":  {
    "status":  "COMBINED_STATUS_READY_FOR_CUTOVER",
    "displayMessage":  "Ready for cutover (1 resources failed)",
    "repositories":  [
      {
        "repositoryNwo":  "new-test-org/my-new-repo",
        "phase":  "REPOSITORY_PHASE_READY_FOR_CUTOVER",
        "displayStatus":  "Ready for cutover (1 failed)"
      }
    ],
    "readyForCutover":  true,
    "cutoverBlockers":  []
  },

Sugerencias:

• Si ejecuta varias migraciones, puede comprobar el estado de todas ellas con elm migration list. Este comando muestra las migraciones en curso de forma predeterminada, pero también puede filtrar por --status.
• Si encuentra estados de error que requieren atención, consulte Solución de problemas de migraciones en vivo de GitHub Enterprise Server a GHE.com.

7. Completar la migración

Cuando una migración esté lista para el cambio final, puede completarla. El proceso de transición bloqueará el repositorio de origen, lo que hace que no esté disponible permanentemente para los desarrolladores a menos que un administrador lo desbloquee.

elm migration cutover-to-destination --migration-id $MIGRATION_ID

elm migration cutover-to-destination --migration-id $MIGRATION_ID

Continúe supervisando la migración. Cuando vea el MIGRATION_STATUS_COMPLETED estado en la parte superior de la respuesta, la migración se ha completado, aunque hay algunas tareas de seguimiento para conceder acceso a los usuarios desde GitHub Enterprise Server.

Pasos siguientes

Proporcione a los usuarios acceso al nuevo repositorio y concilie la actividad con las cuentas de usuario. Consulte Finalización de la migración en vivo desde GitHub Enterprise Server a GHE.com.