Preparación para la migración de la ejecución de pruebas

Este artículo se centra en la preparación del equipo y la generación de archivos que requiere la herramienta de migración de datos.

Requisitos previos

Complete la fase De validación antes de empezar a prepararse para la migración de la ejecución de pruebas.

Generación de la configuración de migración

Realice los pasos siguientes para generar la especificación de migración y los archivos relacionados para poner en cola la migración de la base de datos de recopilación.

1. Ejecute el comando Preparación de la herramienta de migración de datos con los parámetros siguientes:

   /collection:http://localhost:8080/tfs/DefaultCollection/ tenantDomainName:contoso.com /Region:CUS

   • La opción de nombre de dominio de inquilino es el nombre del inquilino de Id. de Microsoft Entra de su empresa.
   • El comando prepare requiere acceso a Internet. Si azure DevOps Server carece de conectividad a Internet, ejecute el comando desde otro equipo.
   • El término "región de la organización" hace referencia a la ubicación en la que planea migrar la colección a Azure DevOps Services. Anteriormente seleccionó una región y registró su código abreviado. Use este código en el comando prepare.

2. Inicie sesión con un usuario del inquilino que tenga permiso para leer información sobre todos los usuarios del inquilino de Microsoft Entra ID.

Configuración del archivo de especificación de migración

El archivo de especificación de migración es un archivo JSON que indica a la Herramienta de migración de datos cómo realizar las siguientes acciones.

• Configuración de la organización migrada
• Especificar las ubicaciones de origen
• Personalización de la migración

Muchos de los campos se rellenan automáticamente durante el paso de preparación, pero debe configurar los campos siguientes:

• Nombre de la organización: el nombre de la organización que desea crear para migrar los datos.
• Ubicación: copia de seguridad de la base de datos y los archivos de migración que se van a cargar en un contenedor de Azure Storage. Este campo especifica la clave SAS que usa la herramienta de migración para conectarse y leer de forma segura los archivos de origen del contenedor de almacenamiento de Azure. La creación del contenedor de almacenamiento se trata más adelante en la fase 5 y la generación de una clave SAS se trata en la fase 6 antes de poner en cola una nueva migración.
• DACPAC: un archivo que empaqueta la base de datos SQL de la colección.
• Tipo de migración: tipo de migración: ejecución de prueba o ejecución de producción.

Cada archivo de especificación de migración está diseñado para una sola colección. Si intenta usar un archivo de especificación de migración generado para otra colección, la migración no se inicia. Debe preparar una ejecución de prueba para cada recopilación que quiera migrar y usar el archivo de especificación de migración generado para poner en cola la migración.

Revisión del archivo de registro de mapa de identidad

El registro de mapa de identidad es crucial, tan importante como los datos reales que migra. Al examinar el archivo de registro, comprenda cómo funciona la migración de identidades y los posibles resultados. Al migrar una identidad, puede ser activa o histórica. Las identidades activas pueden iniciar sesión en Azure DevOps Services, mientras que las identidades históricas no pueden hacerlo. El servicio decide qué tipo se usa.

Nota:

Una vez que una identidad se migra como una identidad histórica, no hay forma de convertirla en una activa.

Identidades activas

Las identidades activas hacen referencia a identidades de usuario en Azure DevOps Services después de la migración. En Azure DevOps Services, estas identidades tienen licencia y se muestran como usuarios de la organización. Las identidades se marcan como activas en la columna Estado de importación esperado en el archivo de registro de mapa de identidades.

Identidades históricas

Las identidades históricas se asignan como tal en la columna Estado de importación esperado del archivo de registro de mapa de identidad. Las identidades sin una entrada de línea en el archivo también se convierten en históricos. Un ejemplo de identidad sin una entrada de línea podría ser un empleado que ya no trabaja en una empresa.

A diferencia de las identidades activas, las identidades históricas:

• No tiene acceso a una organización después de la migración.
• No tenga licencias.
• No aparezca como usuarios de la organización. Todo lo que persiste es la noción de ese nombre de identidad en la organización, de modo que su historial se pueda buscar más adelante. Se recomienda usar identidades históricas para los usuarios que ya no trabajan en la empresa o que no necesitan más acceso a la organización.

Nota:

Después de que una identidad se migre como histórica, no puede activarla.

Licencias

Durante la migración, las licencias se asignan automáticamente a todos los usuarios que se muestran como "activas" en la columna Estado de importación esperado del registro de asignación de identidades. Si la asignación automática de licencias es incorrecta, puede cambiarla editando el "nivel de acceso" de uno o varios usuarios una vez completada la migración.

Es posible que la asignación no siempre sea perfecta, por lo que tiene hasta el primer mes siguiente para reasignar licencias según sea necesario. Si en el primer mes no vincula una suscripción a su organización y adquiere el número correcto de licencias, todas las licencias de período de gracia se revocan. Como alternativa, si la asignación automática asignó más licencias de las que adquirió para el mes siguiente, no le cobramos por las licencias adicionales, pero revocamos todas las licencias no pagadas.

Para evitar perder el acceso, se recomienda vincular una suscripción y comprar licencias necesarias antes del primer mes, ya que la facturación se ejecuta mensualmente. Para todas las ejecuciones de pruebas, las licencias son gratuitas siempre que la organización esté activa.

Suscripciones de Azure DevOps

Suscripciones de Visual Studio no se asignan de forma predeterminada para las migraciones. En su lugar, los usuarios con Suscripciones de Visual Studio se actualizan automáticamente para usar esa licencia. Si la organización profesional de un usuario está vinculada correctamente, Azure DevOps Services aplica automáticamente sus ventajas de su suscripción de Visual Studio en su primera migración posterior al inicio de sesión.

No es necesario repetir una migración de ejecución de prueba si los usuarios no se actualizan automáticamente para usar su suscripción de Visual Studio en Azure DevOps Services. La vinculación de suscripciones de Visual Studio es algo que sucede fuera del ámbito de una migración. Si la organización de trabajo se vincula correctamente antes o después de la migración, el usuario tiene automáticamente su licencia actualizada en el siguiente inicio de sesión. Una vez que se actualicen, la próxima vez que migre el usuario se actualizará automáticamente tras el inicio de sesión inicial a la organización.

Restringir el acceso solo a direcciones IP de Azure DevOps Services

• Opción 1: Usar etiquetas de servicio
• Opción 2: Usar la lista de DIRECCIONES IP

Restrinja el acceso a la cuenta de Azure Storage solo a direcciones IP de Azure DevOps Services. Para restringir el acceso, solo se permiten conexiones desde direcciones IP de Azure DevOps Services implicadas en el proceso de migración de la base de datos de recopilación. Las direcciones IP a las que se debe conceder acceso a la cuenta de almacenamiento dependen de la región a la que va a migrar.

Opción 1: Usar etiquetas de servicio

Puede permitir fácilmente conexiones desde todas las regiones de Azure DevOps Services agregando la azuredevops etiqueta de servicio a los grupos de seguridad de red o firewalls a través del portal o mediante programación.

Opción 2: Usar la lista de DIRECCIONES IP

Use el IpList comando para obtener la lista de direcciones IP a las que se debe conceder acceso para permitir conexiones desde una región específica de Azure DevOps Services.

En la documentación de ayuda se incluyen instrucciones y ejemplos para ejecutar Migrator desde la propia instancia de Azure DevOps Server y una máquina remota. Si ejecuta el comando desde uno de los niveles de aplicación de la instancia de Azure DevOps Server, el comando debe tener la siguiente estructura:

Migrator IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region} 

Puede agregar la lista de direcciones IP a los grupos de seguridad de red o firewalls a través del portal o mediante programación.

Configuración de excepciones de firewall de IP para SQL Azure

Esta sección solo se aplica a la configuración de excepciones de firewall para SQL Azure. Para las migraciones de DACPAC, consulte Configuración de firewalls y redes virtuales de Azure Storage.

La herramienta de migración de datos requiere que las direcciones IP de Azure DevOps Services se configuren solo para las conexiones entrantes en el puerto 1433.

Siga estos pasos para conceder excepciones para las direcciones IP necesarias que se controlan en la capa de red de Azure para la máquina virtual de SQL Azure.

1. Inicie sesión en Azure Portal.
2. Vaya a la máquina virtual de SQL Azure.
3. En Configuración, seleccione Redes.
4. Seleccione Agregar regla de puerto de entrada.
5. Seleccione Avanzado para configurar una regla de puerto de entrada para una dirección IP específica.
6. En la lista desplegable Origen , seleccione Direcciones IP, escriba una dirección IP que deba concederse una excepción, establezca el intervalo1433 de puertos de destino en y, en el cuadro Nombre , escriba un nombre que describa mejor la excepción que está configurando.

En función de otras reglas de puerto de entrada configuradas, es posible que tenga que cambiar la prioridad predeterminada para las excepciones de Azure DevOps Services, por lo que no se omiten. Por ejemplo, si tiene una regla de "denegación en todas las conexiones entrantes a 1433" con una prioridad más alta que las excepciones de Azure DevOps Services, es posible que la herramienta de migración de datos no pueda realizar una conexión correcta a la base de datos.

Repita la adición de reglas de puerto de entrada hasta que se conceda una excepción a todas las direcciones IP de Azure DevOps Services necesarias. Si falta una dirección IP, la migración no se puede iniciar.

Migración de colecciones grandes

En el caso de las bases de datos que advierte la herramienta de migración de datos son demasiado grandes, se requiere un enfoque de empaquetado de datos diferente para migrar a Azure DevOps Services. Si no está seguro de si la colección supera el umbral de tamaño, debe ejecutar una validación de la Herramienta de migración de datos en la colección. La validación le permite saber si necesita usar el método de máquina virtual de SQL Azure para la migración.

Determinar si puede reducir el tamaño de la colección

Compruebe si puede limpiar los datos antiguos. Con el tiempo, las colecciones pueden crear grandes volúmenes de datos. Este crecimiento es una parte natural del proceso de DevOps, pero es posible que no necesite conservar todos los datos. Algunos ejemplos comunes de datos ya no relevantes son áreas de trabajo antiguas y resultados de compilación.

La Herramienta de migración de datos examina la colección y la compara con los límites mencionados anteriormente. A continuación, notifica si la colección es apta para el método de migración DACPAC o SQL. En general, la idea es que si la colección es lo suficientemente pequeña como para ajustarse a los límites de DACPAC, puede usar el enfoque DACPAC más rápido y sencillo. Sin embargo, si la colección es demasiado grande, debe usar el método de migración de SQL, lo que implica configurar una máquina virtual de SQL Azure y migrar la base de datos manualmente.

Límites de tamaño

Los límites actuales son:

• 150 GB de tamaño total de la base de datos (metadatos de base de datos + blobs) para DACPAC, si supera este límite, debe realizar el método de migración de SQL.
• Tamaño de tabla individual de 30 GB (metadatos de base de datos + blobs) para DACPAC, si alguna tabla única supera este límite, debe realizar el método de migración de SQL.
• Tamaño de metadatos de base de datos de 1536 GB para el método de migración de SQL. Al superar este límite se emite una advertencia, le recomendamos que mantenga bajo este tamaño para tener una migración correcta.
• Tamaño de metadatos de base de datos de 2048 GB para el método de migración de SQL. Si se supera este límite, se produce un error, por lo que no se puede realizar una migración.
• No hay límite para los tamaños de blob para el método de migración de SQL.

Cuando limpia artefactos más antiguos y ya no relevantes, podría quitar mucho más espacio de lo esperado y podría determinar si usa el método de migración DACPAC o una máquina virtual de Sql Azure.

Importante

Una vez eliminados los datos más antiguos, no se puede recuperar a menos que restaure una copia de seguridad anterior de la colección.

Si está bajo el umbral de DACPAC, siga las instrucciones para generar un DACPAC para la migración. Si todavía no puede obtener la base de datos bajo el umbral de DACPAC, debe configurar una máquina virtual de Azure con SQL para migrar a Azure DevOps Services.

Configuración de una máquina virtual de Sql Azure para migrar a Azure DevOps Services

Siga estos pasos generales para configurar una máquina virtual (VM) de SQL Azure para migrar a Azure DevOps Services.

1. Configuración de una máquina virtual de SQL Azure
2. Configuración de excepciones de firewall de IP
3. Restauración de la base de datos en la máquina virtual
4. [Configuración de la recopilación para la migración
5. Configuración del archivo de especificación de migración para tener como destino la máquina virtual

Configuración de una máquina virtual de SQL Azure

Puede configurar rápidamente una máquina virtual de SQL Azure desde Azure Portal. Para más información, consulte Uso de Azure Portal para aprovisionar una máquina virtual Windows con SQL Server.

El rendimiento de la máquina virtual de SQL Azure y los discos de datos conectados tienen un impacto significativo en el rendimiento de la migración. Por este motivo, se recomienda encarecidamente realizar las siguientes tareas:

• Seleccione un tamaño de máquina virtual en el nivel de D8s_v5_* o superior.
• Usar discos administrados.
• Consulte el rendimiento de la máquina virtual y del disco. Asegúrese de que la infraestructura está configurada para que las IOPS de máquina virtual (entrada/salida por segundo) y las IOPS de almacenamiento no se conviertan en un cuello de botella en el rendimiento de la migración. Por ejemplo, asegúrese de que el número de discos de datos conectados a la máquina virtual es suficiente para admitir las IOPS desde la máquina virtual.

Azure DevOps Services está disponible en varias regiones de Azure en todo el mundo. Para asegurarse de que la migración se inicia correctamente, es fundamental colocar los datos en la región correcta. Si configura la máquina virtual de SQL Azure en una ubicación incorrecta, la migración no se puede iniciar.

Importante

La máquina virtual de Azure requiere una dirección IP pública.

Si usa este método de migración, cree la máquina virtual en una región admitida. Aunque Azure DevOps Services está disponible en varias regiones de la Estados Unidos (EE. UU.), solo la región central Estados Unidos acepta nuevas organizaciones. Ahora no puede migrar los datos a otras regiones de Azure de EE. UU.

Nota:

Los clientes de DACPAC deben consultar la tabla de regiones en la sección "Paso 3: Cargar el archivo DACPAC](migration-test-run.md#)". Las instrucciones anteriores son solo para SQL Azure máquinas virtuales. Si es cliente de DACPAC, consulte regiones de Azure admitidas para la migración.

Use las siguientes configuraciones de máquina virtual de Sql Azure:

• Configure la base de datos temporal de SQL para usar una unidad distinta de la unidad C. Lo ideal es que la unidad tenga suficiente espacio libre; al menos equivalente a la tabla más grande de la base de datos.
• Si la base de datos de origen sigue siendo superior a 1 terabyte (TB) después de reducir su tamaño, debe conectar más discos de 1 TB y combinarlos en una sola partición para restaurar la base de datos en la máquina virtual.
• Si las bases de datos de recopilación tienen un tamaño superior a 1 TB, considere la posibilidad de usar un SSD (unidades de disco duro de estado sólido) para la base de datos temporal y la base de datos de recopilación. Además, considere la posibilidad de usar máquinas virtuales más grandes con 16 CPU virtuales (vCPU) y 128 GB (gigabytes) de RAM (memoria de acceso aleatorio).

Restauración de la base de datos en la máquina virtual

Después de configurar y configurar una máquina virtual de Azure, debe realizar la copia de seguridad desasociada de la instancia de Azure DevOps Server en la máquina virtual de Azure. La base de datos de recopilación debe restaurarse en la instancia de SQL y no requiere que se instale Azure DevOps Server en la máquina virtual.

Configuración de la recopilación para la migración

Una vez que la base de datos de recopilación se restaura en la máquina virtual de Azure, configure un inicio de sesión de SQL para permitir que Azure DevOps Services se conecte a la base de datos para migrar los datos. Este inicio de sesión solo permite el acceso de lectura a una base de datos única.

1. Abra SQL Server Management Studio en la máquina virtual y, a continuación, abra una nueva ventana de consulta en la base de datos que se va a migrar.

2. Establezca la recuperación de la base de datos en simple:

   ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;
   

3. Cree un inicio de sesión de SQL para la base de datos y asígnele el inicio de sesión en "TFSEXECROLE", como en el ejemplo siguiente.

   USE [<database name>] 
   CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>' 
   CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo] 
   EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'
   

Vea el ejemplo siguiente del comando SQL:

    ALTER DATABASE [Foo] SET RECOVERY SIMPLE; 
     
    USE [Foo] 
    CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikamimport1!' 
    CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo] 
    EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

Importante

Habilite SQL Server y autenticación de Windows modo en SQL Server Management Studio en la máquina virtual. Si no habilita el modo de autenticación, se produce un error en la migración.

Configuración del archivo de especificación de migración para tener como destino la máquina virtual

Actualice el archivo de especificación de migración para incluir información sobre cómo conectarse a la instancia de SQL Server. Abra el archivo de especificación de migración y realice las siguientes actualizaciones:

1. Quite el parámetro DACPAC del objeto de archivos de origen. La especificación de migración antes del cambio es similar al código de ejemplo siguiente.

   

   La especificación de migración después del cambio tiene un aspecto similar al código de ejemplo siguiente.

   

2. Escriba los parámetros necesarios y agregue el siguiente objeto de propiedades dentro del objeto de origen en el archivo de especificación.

   "Properties": 
   { 
       "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True"  
   }
   

Después de aplicar los cambios, la especificación de migración es similar al ejemplo siguiente.

La especificación de migración ahora está configurada para usar una máquina virtual de Azure con SQL para la migración. Continúe con el resto de los pasos de preparación para la migración. Una vez finalizada la migración, asegúrese de eliminar el inicio de sesión de SQL o rotar la contraseña. Microsoft no conserva la información de inicio de sesión una vez completada la migración.

Creación de un contenedor de Azure Storage en el centro de datos elegido

El uso de la herramienta de migración de datos para Azure DevOps requiere tener un contenedor de Azure Storage en el mismo centro de datos de Azure que la organización final de Azure DevOps Services. Por ejemplo, si piensa que la organización de Azure DevOps Services se cree en el centro de datos central Estados Unidos, cree el contenedor de Azure Storage en ese mismo centro de datos. Esta acción acelera drásticamente el tiempo necesario para migrar la base de datos SQL, ya que la transferencia se produce dentro del mismo centro de datos.

Para obtener más información, consulte Creación de una cuenta de almacenamiento.

Configuración de facturación

Se coloca un período de gracia en la organización de Azure DevOps Services recién migrada para permitir que el equipo complete los pasos que necesita y corrija las asignaciones de licencias. Si prevé que puede querer comprar más planes de usuario, canalizaciones de compilación o implementación, servicios de compilación hospedados, servicios de prueba de carga hospedados, por ejemplo, le recomendamos encarecidamente que tenga una suscripción de Azure lista para vincularse a la organización migrada. El período de gracia finaliza el primer día del mes siguiente después de completar la migración.

Le recordamos de nuevo en la fase posterior a la migración (vínculo) para cuando necesite realizar la vinculación. Este paso de preparación es más sobre cómo asegurarse de saber qué suscripción de Azure usa en ese paso posterior. Para obtener más información, consulte Configuración de la facturación para su organización.

Pasos siguientes

Prueba de la migración de ejecución

Artículos relacionados

• Migración a Azure DevOps Services
• Completar tareas posteriores a la migración