Skip to main content

Administración del acceso para una migración desde Azure DevOps

Para proteger los datos, aplica requisitos de acceso específicos para usar Enterprise Importer. Estos requisitos varían en función de la tarea que intentas realizar. Para evitar errores, debes revisar este artículo cuidadosamente y comprobar que cumples todos los requisitos de la tarea que quieres completar.

Para migrar un repositorio de Azure DevOps a , necesitas acceso suficiente tanto al origen (una organización en Azure DevOps) como al destino (una organización en ). Para tener acceso suficiente, necesitarás todo lo siguiente.

  • Un rol necesario en la organización de destino en
  • Un personal access token que pueda acceder a la organización de destino en
    • La instancia de personal access token debe tener todos los ámbitos necesarios, que dependen de tu rol y de la tarea que quieras completar.
    • Si la organización de destino usa el inicio de sesión único de SAML para , debes autorizar personal access token para el inicio de sesión único.
  • Un personal access token que pueda acceder a la organización de origen en Azure DevOps.

Además, si usas listas de direcciones IP permitidas con el origen o destino, es posible que tengas que configurar las listas de permitidos para permitir el acceso por Enterprise Importer.

Para quitar la necesidad de que los propietarios de la organización completen las migraciones, en se incluye un rol único para usar Enterprise Importer.

La concesión del rol de migración te permite designar otros equipos o individuos para controlar las migraciones.

  • Solo puedes conceder el rol de migración para una organización en .com o GHE.com.
  • Puedes conceder el rol de migración a un usuario individual o a un equipo. Se recomienda encarecidamente asignar el rol de migración a un equipo. Después, puedes personalizar aún más quién puede ejecutar una migración si ajustas la pertenencia al equipo. Consulta Agregar miembros de la organización a un equipo o Eliminar de un equipo a miembros de la organización.
  • El responsable de la migración debe usar una instancia de personal access token que cumpla todos los requisitos para ejecutar migraciones.

Advertencia

Cuando se concede el rol de migrador en una organización a un usuario o equipo, se le concede la capacidad de importar o exportar cualquier repositorio de esa organización.

Para conceder el rol de migración, consulta Concesión del rol de migración.

Para la organización de destino en , se requieren distintos roles para diferentes tareas.

En la tabla siguiente se enumeran qué tareas pueden realizar qué roles.

TareaPropietario de la organizaciónResponsable de la migración
Asignación del rol de migración para las migraciones de repositorio
Ejecución de una migración de repositorio
Descarga de un registro de migración
Reclamación de maniquíes

Para ejecutar una migración, necesita un personal access token que pueda acceder a la organización de destino en , y otro personal access token que pueda acceder a la organización de origen en Azure DevOps.

Para otras tareas, como descargar un registro de migración, solo necesitas un personal access token que pueda acceder a la organización de destino en .

Los ámbitos necesarios para personal access token (classic) dependen de tu rol y de la tarea que quieras completar.

Nota:

Solo puedes usar un personal access token (classic), no un fine-grained personal access token. Esto significa que no puedes usar Enterprise Importer si tu organización usa la directiva "Restrict personal access tokens (classic) from accessing your organizations". Para más información, consulta Aplicación de directivas de tokens de acceso personal en la empresa.

TareaPropietario de la organizaciónResponsable de la migración
Asignación del rol de migración para las migraciones de repositorioadmin:org
Ejecución de una migración de repositorios (organización de destino)repo, admin:org, workflowrepo, read:org, workflow
Descarga de un registro de migraciónrepo, admin:org, workflowrepo, read:org, workflow
Reclamación de maniquíesadmin:org

El personal access token de Azure DevOps debe tener los ámbitos work item (read), code (read) y identity (read).

Si deseas usar la marca --rewire-pipelines al generar un script de migración, también necesitarás el ámbito Build (Read). Para usar las marcas inventory-report y integrate-boards, deberás conceder acceso completo a personal access token.

Si quieres realizar la migración desde varias organizaciones, permite que personal access token acceda a todas las organizaciones accesibles. Para más información, consulta Uso de personal access token en Microsoft Docs.

Para permitir que alguien que no sea propietario de la organización ejecute una migración o descargue registros de migración, puedes conceder el rol de migración a un usuario o equipo. Para obtener más información, consulta Acerca del rol de migración.

Puedes conceder el rol de migración mediante ADO2GH extension of the CLI o GraphQL API.

Para conceder el rol de migración mediante la CLI, debes haber instalado ADO2GH extension of the CLI. Para más información, consulta Migración de repositorios desde Azure DevOps a  Enterprise Cloud.

  1. En , cree y registre una instancia de personal access token que cumpla todos los requisitos para conceder el rol de migración. Para obtener más información, consulta Creación de un personal access token para .

  2. Establece personal access token como una variable de entorno, y reemplaza TOKEN en los comandos siguientes por el valor personal access token que has registrado antes.

    • Si usas Terminal, utiliza el comando export.

      Shell
      export GH_PAT="TOKEN"
      
    • Si usas PowerShell, utiliza el comando $env.

      Shell
      $env:GH_PAT="TOKEN"
      
  3. Usa el comando gh ado2gh grant-migrator-role, y reemplaza ORGANIZATION por la organización a la que quieras conceder el rol de migración, ACTOR por el nombre de usuario o equipo, y TYPE por USER o TEAM.

    Shell
    gh ado2gh grant-migrator-role ---org ORGANIZATION --actor ACTOR --actor-type TYPE
    

    Nota:

    Si vas a conceder el rol de migración para GHE.com, también debes incluir la dirección URL de la API de destino para el subdominio de la empresa. Por ejemplo: --target-api-url https://api.octocorp.ghe.com.

Puedes usar la mutación grantMigratorRole de GraphQL para asignar el rol de migración y la mutación revokeMigratorRole para revocarlo.

Debes usar una instancia de personal access token (PAT) que cumpla todos los requisitos de acceso. Para más información, consulta Ámbitos obligatorios para instancias de personal access token.

Esta mutación de GraphQL establece el rol de migración.

mutation grantMigratorRole (
  $organizationId: ID!,
  $actor: String!,
  $actor_type: ActorType!
) {
  grantMigratorRole( input: {
    organizationId: $organizationId,
    actor: $actor,
    actorType: $actor_type
  })
   { success }
}
Variable de consultaDescripción
organizationIdValor ownerId (o id. de organización) de la organización, de la consulta GetOrgInfo.
actorEquipo o nombre de usuario al que quieres asignar el rol de migración.
actor_typeEspecifica si el responsable de la migración es USER o TEAM.

Esta mutación elimina el rol de migración.

mutation revokeMigratorRole (
  $organizationId: ID!,
  $actor: String!,
  $actor_type: ActorType!
) {
  revokeMigratorRole( input: {
    organizationId: $organizationId,
    actor: $actor,
    actorType: $actor_type
  })
   { success }
}

  1. Comprueba que tienes un rol suficiente para la tarea que quieres completar. Para más información, consulta Roles obligatorios.
  2. Crea una instancia de personal access token (classic) y asegúrate de conceder todos los ámbitos necesarios para la tarea que quieres completar. Solo puedes usar un personal access token (classic), no un fine-grained personal access token. Para más información, consulta Administración de tokens de acceso personal y Ámbitos obligatorios para personal access token.
  3. Si se aplica el inicio de sesión único de SAML para las organizaciones a las que necesitas acceder, autoriza la instancia de personal access token para el inicio de sesión único. Para más información, consulta Autorizar un token de acceso personal para usar con un inicio de sesión único de SAML.

Si el origen o el destino de la migración usa una lista de direcciones IP permitidas, ya sea la característica de lista de direcciones IP permitidas de , o bien las restricciones de lista de direcciones IP permitidas del proveedor de identidades (IdP), como Azure CAP, debe configurar las listas de direcciones IP permitidas en . Consulta Administrar las direcciones IP permitidas en tu organización y Restricción del tráfico de red a la empresa con una lista de direcciones IP permitidas.

  • Si usas la característica de lista de direcciones IP permitidas de , tendrás que agregar los intervalos IP de siguientes a la lista de permitidos para las organizaciones de origen o destino.
  • Si usa la lista de direcciones IP permitidas del IdP para restringir el acceso a la empresa en , debe deshabilitar estas restricciones en la configuración de la cuenta empresarial hasta que se complete la migración.

Los intervalos IP varían en función de si el destino de la migración es .com o GHE.com.

Deberás agregar los siguientes intervalos IP a las listas de direcciones IP permitidas:

  • 192.30.252.0/22
  • 185.199.108.0/22
  • 140.82.112.0/20
  • 143.55.64.0/20
  • 40.71.233.224/28
  • 2a0a:a440::/29
  • 2606:50c0::/32
  • 20.125.12.8/29 (activo de 00:00 UTC el 8 de noviembre de 2023)

Puedes obtener una lista actualizada de los intervalos IP usados por Enterprise Importer en cualquier momento con el punto de conexión "Obtener información meta de " de la API de REST.

La clave _enterprise_importer de la respuesta contiene una lista de los intervalos IP usados para las migraciones.

Para más información, consulta Puntos de conexión de la API de REST para metadatos.

Debes permitir:

  • Rangos necesarios para todos los usuarios
  • Rangos adicionales que dependen de la región de residencia de datos

Para ver los rangos que se van a agregar, consulta Detalles de red para GHE.com.