Compartir vía

Prueba de la migración de ejecución

  • Artículo

Su equipo ya está listo para comenzar el proceso de iniciar una ejecución de prueba de la migración y, finalmente, una migración de producción completa. En esta fase, se describen los pasos finales para poner en cola una migración, además de otras tareas que suelen aparecer al final del proyecto de migración.

Diagrama que resalta la fase Requisitos previos en fases secuenciales.

Requisitos previos

Complete la fase preparar la ejecución de pruebas antes de comenzar una migración de ejecución de pruebas.

Validación de una colección

Valide cada colección que quiera migrar a Azure DevOps Services. El paso de validación examina varios aspectos de la colección, incluidos, entre otros, el tamaño, la intercalación, la identidad y los procesos.

Ejecute la validación mediante la herramienta de migración de datos.

  1. Descargue la herramienta de migración de datos.

  2. Copie el archivo ZIP en uno de los niveles de aplicación de Azure DevOps Server.

  3. Descomprima el archivo . También puede ejecutar la herramienta desde una máquina diferente sin Azure DevOps Server instalado, siempre y cuando la máquina pueda conectarse a la base de datos de configuración de la instancia de Azure DevOps Server.

  4. Abra una ventana del símbolo del sistema en el servidor y escriba un comando cd para cambiar al directorio donde se almacena la herramienta de migración de datos. Dedique unos instantes a revisar el contenido de ayuda de la herramienta.

    a. Para ver la ayuda y las instrucciones de nivel superior, ejecute el siguiente comando.

     Migrator /help

    b. Vea el texto de ayuda del comando.

     Migrator validate /help

  5. Como primera vez que valida una colección, el comando debe tener la siguiente estructura simple.

     Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}

    Donde {name} proporciona el nombre del inquilino de Microsoft Entra, por ejemplo, para ejecutarse en DefaultCollection y el inquilino fabrikam, el comando tendría el siguiente aspecto.

     Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}

  6. Para ejecutar la herramienta desde una máquina distinta de la Azure DevOps Server, necesita el parámetro /connectionString. El parámetro de cadena de conexión apunta a la base de datos de configuración de Azure DevOps Server. Por ejemplo, si el comando validado se ejecuta por fabrikam corporation, el comando tendría el aspecto.

     Migrator validate /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"

    Importante

    La herramienta de migración de datos no edita datos ni estructuras de la colección. Lee la colección solo para identificar problemas.

  7. Una vez completada la validación, puede ver los archivos de registro y los resultados.

    Captura de pantalla de los resultados y registros de validación en la ventana del símbolo del sistema.

    Durante la validación, recibirá una advertencia si algunas de las canalizaciones contienen reglas de retención por canalización. Azure DevOps Services usa un modelo de retención basado en proyectos y no admite directivas de retención por canalización. Si continúa con la migración, las directivas no se transfieren a la versión hospedada. En su lugar, se aplican las directivas de retención de nivel de proyecto predeterminadas. Conserve las compilaciones importantes para evitar su pérdida.

Después de pasar todas las validaciones, puede pasar al siguiente paso del proceso de migración. Si la herramienta de migración de datos marca los errores, corrijalos antes de continuar. Para obtener instrucciones sobre cómo corregir errores de validación, consulte Solución de problemas de migración y errores de migración.

Importación de archivos de registro

Al abrir el directorio de registro, es posible que observe varios archivos de registro.

El archivo de registro principal se denomina DataMigrationTool.log. Contiene detalles sobre todo lo que se ejecutó. Para que sea más fácil centrarse en áreas específicas, se genera un registro para cada operación de validación principal.

Por ejemplo, si TfsMigrator notifica un error en el paso "Validar procesos de proyecto", puede abrir el archivo ProjectProcessMap.log para ver todo lo que se ejecutó para ese paso en lugar de tener que desplazarse por todo el registro.

Revise el archivo TryMatchOobProcesses.log solo si intenta migrar los procesos del proyecto para usar el modelo heredado. Si no desea usar el modelo heredado, puede omitir estos errores, ya que no le impiden importar a Azure DevOps Services. Para obtener más información, consulte la fase de validación de la migración.

Generación de archivos de migración

La Herramienta de migración de datos validó la colección y devuelve un resultado de "Se han superado todas las validaciones de recopilación". Antes de desconectar una colección para migrarla, genere los archivos de migración. Al ejecutar el prepare comando, se generan dos archivos de migración:

  • IdentityMapLog.csv: describe el mapa de identidad entre Active Directory y Microsoft Entra ID.
  • migration.json: requiere que rellene la especificación de migración que desea usar para iniciar la migración.

Comando Prepare

El prepare comando ayuda a generar los archivos de migración necesarios. Básicamente, este comando examina la colección para buscar una lista de todos los usuarios para rellenar el registro de mapa de identidad, IdentityMapLog.csv e intenta conectarse a Microsoft Entra ID para encontrar la coincidencia de cada identidad. Para ello, su empresa debe usar la herramienta Microsoft Entra Connect (anteriormente conocida como herramienta de sincronización de directorios, herramienta de sincronización de directorios o herramienta de DirSync.exe).

Si se configura la sincronización de directorios, la Herramienta de migración de datos debe encontrar las identidades coincidentes y marcarlas como Activas. Si no hay coincidencias, la identidad se marca como Histórica en el registro de mapa de identidades, por lo que debe investigar por qué el usuario no se incluye en la sincronización de directorios. El archivo de especificación de migración, migration.json, debe rellenarse antes de la migración.

A diferencia del validate comando , prepare requiere una conexión a Internet, ya que necesita conectarse a Microsoft Entra ID para rellenar el archivo de registro de mapa de identidades. Si la instancia de Azure DevOps Server no tiene acceso a Internet, ejecute la herramienta desde una máquina que sí lo haga. Siempre que pueda encontrar una máquina con una conexión de intranet a la instancia de Azure DevOps Server y una conexión a Internet, puede ejecutar este comando. Para obtener ayuda con el prepare comando, ejecute el siguiente comando:

Migrator prepare /help

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

Migrator prepare /collection:{collection URL} /tenantDomainName:{name} /region:{region}

Migrator prepare  /collection:{collection URL} /tenantDomainName:{name} /region:{region} /connectionString:"Data Source={sqlserver};Initial Catalog=Configuration;Integrated Security=True"

El parámetro connectionString es un puntero a la base de datos de configuración de la instancia de Azure DevOps Server. Por ejemplo, si fabrikam corporation ejecuta el prepare comando, el comando tiene un aspecto similar al del ejemplo siguiente:

Migrator prepare /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"

Cuando la herramienta de migración de datos ejecuta el prepare comando , ejecuta una validación completa para asegurarse de que nada ha cambiado con la colección desde la última validación completa. Si se detectan problemas nuevos, no se generan archivos de migración.

Poco después de que el comando empiece a ejecutarse, se muestra una ventana de inicio de sesión de Microsoft Entra. Inicie sesión con una identidad que pertenezca al dominio de inquilino, que se especifica en el comando . Asegúrese de que el inquilino de Microsoft Entra especificado es el que desea que su organización futura esté respaldada. En nuestro ejemplo de Fabrikam, un usuario escribe credenciales similares a la captura de pantalla de ejemplo siguiente.

Importante

No use un inquilino de Microsoft Entra de prueba para una migración de prueba y el inquilino de Producción de Microsoft Entra para la ejecución de producción. El uso de un inquilino de Microsoft Entra de prueba puede dar lugar a problemas de migración de identidades al iniciar la ejecución de producción con el inquilino de Producción de Microsoft Entra de la organización.

Al ejecutar el prepare comando correctamente en la herramienta de migración de datos, la ventana de resultados muestra un conjunto de registros y dos archivos de migración. En el directorio de registro, busque una carpeta de registros y dos archivos:

  • migration.json es el archivo de especificación de migración. Le recomendamos que dedique tiempo a rellenarlo.
  • IdentityMapLog.csv contiene la asignación generada de Active Directory a identidades de Microsoft Entra. Repase por integridad antes de iniciar una migración.

Los dos archivos se describen con más detalle en las secciones siguientes.

El archivo de especificación de migración

La especificación de migración, migration.json, es un archivo JSON que proporciona la configuración de migración. Incluye el nombre de la organización deseado, la información de la cuenta de almacenamiento y otra información. La mayoría de los campos se rellenan automáticamente y algunos campos requieren la entrada antes de intentar una migración.

Captura de pantalla de un archivo de especificación de migración recién generado.

Los campos mostrados del archivo migration.json y las acciones necesarias se describen en la tabla siguiente:

Campo Descripción Acción necesaria
Source Información sobre la ubicación y los nombres de los archivos de datos de origen que se usan para la migración. No es necesaria ninguna acción. Revise la información de las acciones del subcampo que se van a seguir.
Location Clave de firma de acceso compartido a la cuenta de Almacenamiento de Azure que hospeda el paquete de aplicación de capa de datos (DACPAC). No es necesaria ninguna acción. Este campo se trata en un paso posterior.
Archivos Nombres de los archivos que contienen datos de migración. No es necesaria ninguna acción. Revise la información de las acciones del subcampo que se van a seguir.
DACPAC Un archivo DACPAC que empaqueta la base de datos de recopilación que se usará para incorporar los datos durante la migración. No es necesaria ninguna acción. En un paso posterior, creará este archivo mediante la recopilación y, a continuación, lo cargará en una cuenta de Almacenamiento de Azure. Actualice el archivo en función del nombre que use al generarlo más adelante en este proceso.
Destino Propiedades de la nueva organización a la que se va a migrar. No es necesaria ninguna acción. Revise la información de las acciones del subcampo que se van a seguir.
Nombre Nombre de la organización que se va a crear durante la migración. Proporcione un nombre. El nombre se puede cambiar rápidamente después de que se complete la migración.
NOTA: No cree una organización con este nombre antes de ejecutar la migración. La organización se crea como parte del proceso de migración.
ImportType Tipo de migración que desea ejecutar. No es necesaria ninguna acción. En un paso posterior, seleccione el tipo de migración que se va a ejecutar.
Datos de validación Información necesaria para ayudar a impulsar la experiencia de migración. La herramienta de migración de datos genera la sección "ValidationData". Contiene información para ayudar a impulsar la experiencia de migración. No edite los valores de esta sección o la migración podría no iniciarse.

Después de completar el proceso anterior, debe tener un archivo similar al ejemplo siguiente.

Captura de pantalla de un archivo de especificación de migración completado parcialmente.

En la imagen anterior, el planificador de la migración de Fabrikam agregó el nombre de organización fabrikam-import y cuS seleccionado (Central Estados Unidos) como ubicación geográfica para la migración. Se dejaron otros valores tal como se van a modificar justo antes de que el planificador desconecte la colección para la migración.

Nota:

Las importaciones de ejecución de pruebas tienen un "-dryrun" anexado automáticamente al final del nombre de la organización, que puede cambiar después de la migración.

Regiones de Azure admitidas para la migración

Azure DevOps Services está disponible en varias ubicaciones geográficas de Azure. Pero no todas las ubicaciones en las que Azure DevOps Services está disponible son compatibles con la migración. En la tabla siguiente se enumeran las ubicaciones geográficas de Azure que puede seleccionar para la migración. También se incluye el valor que debe colocar en el archivo de especificación de migración para dirigirse a esa geografía para la migración.

Ubicación geográfica Ubicación geográfica de Azure Valor de especificación de importación
Estados Unidos Estados Unidos central CUS
Europa Europa Occidental WEU
Reino Unido Sur de Reino Unido UKS
Australia Este de Australia EAU
Sudamérica Sur de Brasil SBR
Asia Pacífico Sur de la India MA
Asia Pacífico Sudeste Asiático (Singapur) SEA
Canadá Canadá central CC

Registro de mapa de identidad

El registro de mapa de identidad es de igual importancia para los datos reales que migra a Azure DevOps Services. A medida que revise el archivo, es importante comprender cómo funciona la migración de identidades y cuáles podrían implicar los resultados potenciales. Al migrar una identidad, puede volverse activa o histórica. Las identidades activas pueden iniciar sesión en Azure DevOps Services, pero las identidades históricas no pueden.

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 identidad.

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 importar una identidad como histórica, no se puede activar.

Descripción del archivo de registro de mapa de identidades

El archivo de registro de mapa de identidad es similar al ejemplo que se muestra aquí:

Captura de pantalla de un archivo de registro de mapa de identidad generado por la herramienta de migración de datos.

Las columnas del archivo de registro de mapa de identidad se describen en la tabla siguiente:

Usted y su administrador de Microsoft Entra deben investigar a los usuarios marcados como No Match Found (Comprobar sincronización de id. de Microsoft Entra) para comprender por qué no forman parte de la sincronización de Microsoft Entra Connect.

Columna Descripción
Active Directory: usuario (Azure DevOps Server) Nombre para mostrar descriptivo usado por la identidad en Azure DevOps Server. Este nombre facilita la identificación del usuario a la que hace referencia la línea del mapa.
Active Directory: identificador de seguridad Identificador único de la identidad de Active Directory local en Azure DevOps Server. Esta columna se usa para identificar a los usuarios de la colección.
Microsoft Entra ID: Usuario de importación esperado (Azure DevOps Services) La dirección de inicio de sesión esperada del usuario activo coincidente pronto a ser activo o No Match Found (Comprobar sincronización de id. de Entra de Microsoft), que indica que la identidad se perdió durante la sincronización de id. de Entra de Microsoft y se importa como histórica.
Estado de importación esperado El estado de migración de usuario esperado: activo si hay una coincidencia entre active Directory y el identificador de Microsoft Entra o Histórico si no hay ninguna coincidencia.
Fecha de validación La última vez que se validó el registro de asignación de identidades.

A medida que lea el archivo, observe si el valor de la columna Estado de importación esperado es Activo o Histórico. Activo indica que la identidad de esta fila se asigna correctamente en la migración se activa. Histórico significa que las identidades se convierten en históricas en la migración. Es importante revisar el archivo de asignación generado para que sea completo y correcto.

Importante

Se produce un error en la migración si se producen cambios importantes en la sincronización del identificador de seguridad de Microsoft Entra Connect entre los intentos de migración. Puede agregar nuevos usuarios entre las ejecuciones de prueba y puede realizar correcciones para asegurarse de que las identidades históricas importadas previamente estén activas. Pero no puede cambiar un usuario existente que se importó previamente como activo. Si lo hace, se producirá un error en la migración. Un ejemplo de un cambio podría estar completando una migración de ejecución de prueba, eliminando una identidad del identificador de Entra de Microsoft que se importó activamente, volver a crear un nuevo usuario en Microsoft Entra ID para esa misma identidad y, a continuación, intentar otra migración. En este caso, una migración de identidad activa intenta entre Active Directory y la identidad de Microsoft Entra recién creada, pero produce un error de migración.

  1. Revise las identidades coincidentes correctamente. ¿Están presentes todas las identidades esperadas? ¿Los usuarios están asignados a la identidad correcta de Microsoft Entra?

    Si se deben cambiar los valores, póngase en contacto con el administrador de Microsoft Entra para comprobar que la identidad de Active Directory local forma parte de la sincronización con el identificador de Microsoft Entra y se configura correctamente. Para obtener más información, consulte Integración de las identidades locales con el identificador de Microsoft Entra.

  2. A continuación, revise las identidades etiquetadas como históricas. Este etiquetado implica que no se encontró una identidad de Microsoft Entra coincidente, por cualquiera de los siguientes motivos:

    • La identidad no está configurada para la sincronización entre Active Directory local y el identificador de Microsoft Entra.
    • La identidad aún no se rellena en el identificador de Entra de Microsoft (por ejemplo, hay un nuevo empleado).
    • La identidad no existe en la instancia de Microsoft Entra.
    • El usuario que posee esa identidad ya no funciona en la empresa.

Para abordar las tres primeras razones, configure la identidad Active Directory local prevista para sincronizarse con el identificador de Entra de Microsoft. Para obtener más información, consulte Integración de las identidades locales con el identificador de Microsoft Entra. Debe configurar y ejecutar Microsoft Entra Connect para que las identidades se importen como activas en Azure DevOps Services.

Puede omitir el cuarto motivo, porque los empleados que ya no están en la empresa deben importarse como históricos.

Identidades históricas (equipos pequeños)

Nota:

Solo los equipos pequeños deben tener en cuenta la estrategia de migración de identidades propuesta en esta sección.

Si Microsoft Entra Connect no está configurado, todos los usuarios del archivo de registro de mapa de identidad se marcan como históricos. Al ejecutar una migración de esta manera, todos los usuarios se importan como históricos. Se recomienda encarecidamente configurar Microsoft Entra Connect para asegurarse de que los usuarios se importan como activos.

La ejecución de una migración con todas las identidades históricas tiene consecuencias que deben tenerse en cuenta cuidadosamente. Solo los equipos con algunos usuarios y para los que el costo de configurar Microsoft Entra Connect se considera demasiado alto.

Para migrar todas las identidades como históricas, siga los pasos descritos en secciones posteriores. Al poner en cola una migración, la identidad usada para poner en cola la migración se arranca en la organización como propietario de la organización. Todos los demás usuarios se importan como históricos. Los propietarios de la organización pueden agregar los usuarios de nuevo mediante su identidad de Microsoft Entra. Los usuarios agregados se tratan como nuevos usuarios. No poseen ninguna de sus historia y no hay forma de reparentar este historial con la identidad de Microsoft Entra. Sin embargo, los usuarios todavía pueden buscar su historial de premigración buscando su \<domain>\<Active Directory username>.

La herramienta de migración de datos muestra una advertencia si detecta el escenario completo de identidades históricas. Si decide bajar esta ruta de migración, debe dar su consentimiento en la herramienta a las limitaciones.

Suscripciones de Visual Studio

La herramienta de migración de datos no puede detectar suscripciones de Visual Studio (anteriormente conocidas como ventajas de MSDN) cuando genera el archivo de registro de mapa de identidades. En su lugar, se recomienda aplicar la característica de actualización automática de licencias después de la migración. Siempre que las cuentas profesionales de los usuarios estén vinculadas correctamente, Azure DevOps Services aplica automáticamente sus ventajas de su suscripción de Visual Studio en su primer inicio de sesión después de la migración. Nunca se le cobrarán las licencias asignadas durante la migración, por lo que puede controlar de forma segura las suscripciones después.

No es necesario repetir una migración de ejecución de prueba si las suscripciones de Visual Studio de los usuarios no se actualizan automáticamente en Azure DevOps Services. La vinculación de suscripciones de Visual Studio se produce fuera del ámbito de una migración. Siempre que su cuenta profesional esté vinculada correctamente antes o después de la migración, las licencias de los usuarios se actualizarán automáticamente en su siguiente inicio de sesión. Una vez que sus licencias se actualicen correctamente, la próxima vez que ejecute una migración, los usuarios se actualizarán automáticamente en su primer inicio de sesión a la organización.

Preparación para la migración

Ahora ya tiene todo listo para ejecutarse en la migración de ejecución de pruebas. Programe el tiempo de inactividad con el equipo para desconectar la recopilación para la migración. Cuando acepte la ejecución de la migración, cargue los recursos necesarios que generó y una copia de la base de datos en Azure. La preparación para la migración consta de los cinco pasos siguientes.

Paso 1: Desconectar la colección y desasociarla. Paso 2: Generar un archivo DACPAC a partir de la colección que va a migrar.
Paso 3: Cargar el archivo DACPAC y los archivos de migración en una cuenta de Almacenamiento de Azure.
Paso 4: Generar un token de SAS para acceder a la cuenta de almacenamiento.
Paso 5: Completar la especificación de migración.

Nota:

Antes de realizar una migración de producción, se recomienda encarecidamente completar una migración de ejecución de prueba. Con una ejecución de prueba, puede validar que el proceso de migración funciona para la recopilación y que no hay formas de datos únicas presentes que podrían provocar un error de migración de producción.

Paso 1: Desasociar la colección

Desasociar la colección es un paso fundamental en el proceso de migración. Los datos de identidad de la colección residen en la base de datos de configuración de la instancia de Azure DevOps Server mientras la colección está adjunta y en línea. Cuando una colección se desasocia de la instancia de Azure DevOps Server, toma una copia de esos datos de identidad y lo empaqueta con la colección para el transporte. Sin estos datos, no se puede ejecutar la parte de identidad de la migración.

Sugerencia

Se recomienda mantener la colección desasociada hasta que se complete la migración, ya que no hay ninguna manera de migrar los cambios que se produjeron durante la migración. Vuelva a adjuntar la colección después de realizar una copia de seguridad para la migración, por lo que no le preocupa tener los datos más recientes para este tipo de migración. Para evitar el tiempo sin conexión por completo, también puede optar por emplear una desasociación sin conexión para las ejecuciones de pruebas.

Es importante ponderar el costo de elegir incurrir en un tiempo de inactividad cero para una ejecución de prueba. Requiere realizar copias de seguridad de la colección y la base de datos de configuración, restaurarlas en una instancia de SQL y, a continuación, crear una copia de seguridad desasociada. Un análisis de costos podría demostrar que, al final, tomar tan solo unas horas de tiempo de inactividad para tomar directamente la copia de seguridad desasociada.

Paso 2: Generar un archivo DACPAC

Los DACPAC ofrecen un método rápido y relativamente sencillo para mover colecciones a Azure DevOps Services. Sin embargo, después de que un tamaño de base de datos de recopilación supere un umbral determinado, las ventajas de usar un DACPAC comienzan a disminuir.

Nota:

Si la herramienta de migración de datos muestra una advertencia que no puede usar el método DACPAC, debe realizar la migración mediante el método máquina virtual (VM) de SQL Azure. Omita los pasos 2 a 5 en ese caso y siga las instrucciones de la sección Preparación de la fase de ejecución de pruebas, Migración de colecciones grandes y, a continuación, continúe para determinar el tipo de migración. Si la herramienta de migración de datos no muestra una advertencia, use el método DACPAC descrito en este paso.

DACPAC es una característica de SQL Server que permite empaquetar bases de datos en un único archivo e implementarlas en otras instancias de SQL Server. Un archivo DACPAC también se puede restaurar directamente en Azure DevOps Services, por lo que puede usarlo como método de empaquetado para obtener los datos de la colección en la nube.

Importante

  • Al usar SqlPackage.exe, debe usar la versión de .NET Framework de SqlPackage.exe para preparar el DACPAC. El instalador msi debe usarse para instalar la versión de .NET Framework de SqlPackage.exe. No use la CLI de dotnet ni las versiones de .zip (Windows .NET 6) de SqlPackage.exe porque esas versiones pueden generar DACPACs incompatibles con Azure DevOps Services.
  • La versión 161 de SqlPackage cifra conexione de base de datos de forma predeterminada y podría no conectarse. Si recibe un error de proceso de inicio de sesión, agregue ;Encrypt=False;TrustServerCertificate=True al cadena de conexión de la instrucción SqlPackage.

Descargue e instale SqlPackage.exe con el instalador MSI más reciente de las notas de la versión de SqlPackage.

Después de usar el instalador msi, SqlPackage.exe instala en una ruta de acceso similar a %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\.

Al generar un DACPAC, tenga en cuenta dos consideraciones: el disco en el que se guarda el DACPAC y el espacio en disco en la máquina que genera el DACPAC. Quiere asegurarse de que tiene suficiente espacio en disco para completar la operación.

A medida que crea el paquete, SqlPackage.exe almacena temporalmente los datos de la colección en el directorio temporal de la unidad C de la máquina desde la que va a iniciar la solicitud de empaquetado.

Es posible que la unidad C sea demasiado pequeña para admitir la creación de un DACPAC. Puede calcular la cantidad de espacio que necesita buscando la tabla más grande de la base de datos de recopilación. Las DACPAC se crean una tabla a la vez. El requisito de espacio máximo para ejecutar la generación es aproximadamente equivalente al tamaño de la tabla más grande de la base de datos de la colección. Si guarda el DACPAC generado en la unidad C, tenga en cuenta el tamaño de la base de datos de recopilación como se indica en el archivo de DataMigrationTool.log desde una ejecución de validación.

El archivo DataMigrationTool.log proporciona una lista de las tablas más grandes de la colección cada vez que se ejecuta el comando. Para obtener un ejemplo de tamaños de tabla para una colección, consulte la salida siguiente. Compare el tamaño de la tabla más grande con el espacio libre en la unidad que hospeda el directorio temporal.

Importante

Antes de continuar con la generación de un archivo DACPAC, asegúrese de que la colección está desasociada.

[Info   @08:23:59.539] Table name                               Size in MB
[Info   @08:23:59.539] dbo.tbl_Content                          38984
[Info   @08:23:59.539] dbo.tbl_LocalVersion                     1935
[Info   @08:23:59.539] dbo.tbl_Version                          238
[Info   @08:23:59.539] dbo.tbl_FileReference                    85
[Info   @08:23:59.539] dbo.Rules                                68
[Info   @08:23:59.539] dbo.tbl_FileMetadata                     61

Asegúrese de que la unidad que hospeda el directorio temporal tenga al menos tanto espacio libre. Si no es así, debe redirigir el directorio temporal estableciendo una variable de entorno.

SET TEMP={location on disk}

Otra consideración es dónde se guardan los datos de DACPAC. Apuntar la ubicación guardada a una unidad remota lejana podría dar lugar a tiempos de generación más largos. Si una unidad rápida, como una unidad de estado sólido (SSD) está disponible localmente, se recomienda tener como destino la unidad como ubicación de guardado de DACPAC. De lo contrario, siempre es más rápido usar un disco en el equipo donde reside la base de datos de recopilación en lugar de una unidad remota.

Ahora que identificó la ubicación de destino para DACPAC y se ha asegurado de que tiene espacio suficiente, es el momento de generar el archivo DACPAC.

Abra una ventana del símbolo del sistema y vaya a la ubicación SqlPackage.exe. Para generar el DACPAC, reemplace los valores de marcador de posición por los valores necesarios y, a continuación, ejecute el siguiente comando:

SqlPackage.exe /sourceconnectionstring:"Data Source={database server name};Initial Catalog={Database Name};Integrated Security=True" /targetFile:{Location & File name} /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory
  • Origen de datos: instancia de SQL Server que hospeda la base de datos de recopilación de Azure DevOps Server.
  • Catálogo inicial: nombre de la base de datos de colección.
  • targetFile: ubicación en el disco y el nombre del archivo DACPAC.

En el ejemplo siguiente se muestra un comando de generación de DACPAC que se ejecuta en la capa de datos Azure DevOps Server:

SqlPackage.exe /sourceconnectionstring:"Data Source=localhost;Initial Catalog=Foo;Integrated Security=True" /targetFile:C:\DACPAC\Foo.dacpac /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

La salida del comando es un archivo DACPAC, generado a partir de la base de datos de recopilación Foo denominada Foo.dacpac.

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.

Para empezar, 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 importar.

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

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

Cree un inicio de sesión de SQL para la base de datos y asígnele el inicio de sesión "TFSEXECROLE":

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>'

Siguiendo nuestro ejemplo de Fabrikam, los dos comandos SQL tendría un aspecto similar al ejemplo siguiente:

ALTER DATABASE [Fabrikam] SET RECOVERY SIMPLE;

USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikampassword'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

Nota:

Habilite SQL Server y el modo de autenticación de Windows 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 se muestra en el código siguiente.

    Captura de pantalla de la especificación de migración antes del cambio.

    La especificación de migración después del cambio se muestra en el código siguiente.

    Captura de pantalla de la especificación de migración después del cambio.

  2. Rellene los parámetros necesarios y agregue el objeto de propiedades siguiente 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.

Captura de pantalla de la especificación de migración que hace referencia a una máquina virtual de SQL Azure.

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 a Azure DevOps Services. 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 finalizada la migración.

Paso 3: Cargar el archivo DACPAC

Nota

Si usa el método de máquina virtual SQL Azure, solo debe proporcionar la cadena de conexión. No tiene que cargar ningún archivo y puede omitir este paso.

El DACPAC debe colocarse en un contenedor de almacenamiento de Azure, que puede ser un contenedor existente o uno creado específicamente para el esfuerzo de migración. Es importante asegurarse de que el contenedor se crea en las ubicaciones geográficas adecuadas.

Azure DevOps Services está disponible en varias ubicaciones geográficas. Cuando se importan a estas ubicaciones, es fundamental colocar los datos correctamente para asegurarse de que la migración se pueda iniciar correctamente. Los datos deben colocarse en la misma ubicación geográfica a la que va a importar. La colocación de los datos en cualquier otro lugar hace que la migración no se pueda iniciar. En la tabla siguiente se enumeran las ubicaciones geográficas aceptables para crear la cuenta de almacenamiento y cargar los datos.

Ubicación geográfica de migración deseada Ubicación geográfica de la cuenta de almacenamiento
Estados Unidos central Estados Unidos central
Europa Occidental Europa Occidental
Reino Unido Sur de Reino Unido
Este de Australia Este de Australia
Sur de Brasil Sur de Brasil
Sur de India Sur de India
Centro de Canadá Centro de Canadá
Asia Pacífico (Singapur) Asia Pacífico (Singapur)

Aunque Azure DevOps Services está disponible en varias ubicaciones geográficas de EE. UU., solo la ubicación central de Estados Unidos acepta nuevos servicios de Azure DevOps. No puede migrar los datos a otras ubicaciones de Azure de EE. UU. en este momento.

Cree un contenedor de blobs desde Azure Portal. Después de crear el contenedor, cargue el archivo DACPAC de colección.

Una vez finalizada la migración, elimine el contenedor de blobs y la cuenta de almacenamiento que lo acompaña con herramientas como AzCopy o cualquier otra herramienta del explorador de Azure Storage, como Explorador de Azure Storage.

Nota:

Si el archivo DACPAC es superior a 10 GB, se recomienda usar AzCopy. AzCopy tiene compatibilidad con cargas multiproceso para cargas más rápidas.

Paso 4: Generación de un token de SAS

Un token de firma de acceso compartido (SAS) proporciona acceso delegado a los recursos de una cuenta de almacenamiento. El token le permite conceder a Microsoft el nivel de privilegio más bajo necesario para acceder a los datos para ejecutar la migración.

Puede generar tokens de SAS mediante Azure Portal. Desde un punto de vista de seguridad, se recomienda realizar las siguientes tareas:

  1. Seleccione Solo lectura y lista como permisos para el token de SAS. No se requieren otros permisos.
  2. Establezca un tiempo de expiración superior a siete días en el futuro.
  3. Restrinja el acceso solo a direcciones IP de Azure DevOps Services.
  4. Trate la clave SAS como un secreto. No deje la clave en una ubicación no segura, ya que concede acceso de lectura y lista a los datos almacenados en el contenedor.

Paso 5: Completar la especificación de migración

Anteriormente en el proceso rellenaba parcialmente el archivo de especificación de migración, conocido como migration.json. En este punto, tiene suficiente información para completar todos los campos restantes, excepto para el tipo de migración. El tipo de migración se trata más adelante, en la sección migración.

En el archivo de especificación migration.json , en Origen, complete los campos siguientes.

  • Ubicación: pegue la clave SAS que generó a partir del script y, a continuación, copie en el paso anterior.
  • Dacpac: asegúrese de que el archivo, incluida la extensión de archivo .dacpac , tiene el mismo nombre que el archivo DACPAC que cargó en la cuenta de almacenamiento.

El archivo de especificación de migración final debe tener un aspecto similar al del ejemplo siguiente.

Captura de pantalla del archivo de especificación de migración completado.

Determinar el tipo de migración

Las importaciones se pueden poner en cola como una ejecución de prueba o una ejecución de producción. El parámetro ImportType determina el tipo de migración:

  • TestRun: use una ejecución de pruebas con fines de prueba. El sistema elimina las pruebas después de 45 días.
  • ProductionRun: use una ejecución de producción cuando quiera mantener la migración resultante y use la organización a tiempo completo en Azure DevOps Services una vez finalizada la migración.

Sugerencia

Siempre se recomienda completar primero una migración de ejecución de prueba.

Prueba de las organizaciones de ejecución

Las organizaciones de ejecución de pruebas ayudan a los equipos a probar la migración de sus colecciones. Para poder ejecutar una migración de producción, se deben eliminar las organizaciones de ejecución de pruebas completadas. Todas las organizaciones de ejecución de pruebas tienen una existencia limitada y se eliminan automáticamente después de un período de tiempo establecido. La información sobre cuándo se elimina la organización se incluye en el correo electrónico correcto que debe recibir una vez finalizada la migración. Asegúrese de tomar nota de esta fecha y planear en consecuencia.

Las organizaciones de ejecución de pruebas tienen 45 días antes de que se eliminen. Después del período de tiempo especificado, se elimina la organización de la ejecución de pruebas. Puede repetir la ejecución de pruebas importa tantas veces como necesite antes de realizar una migración de producción.

Eliminar ejecuciones de pruebas

Elimine las ejecuciones de pruebas anteriores antes de intentar una nueva. Cuando el equipo esté listo para realizar una migración de producción, debe eliminar manualmente la organización de ejecución de pruebas. Para poder ejecutar una segunda migración de ejecución de prueba o la migración de producción final, asegúrese de eliminar las organizaciones anteriores de Azure DevOps Services que creó en una ejecución de prueba anterior. Para obtener más información, consulte Eliminar organización.

Sugerencia

Información opcional para ayudar a un usuario a ser más correctaAny test run migration that follows the first is expected to take longer given the extra time required to clean up resources from previous test runs.

Un nombre de organización puede tardar hasta una hora en estar disponible después de eliminar o cambiar el nombre. Para obtener más información, consulte el artículo Tareas posteriores a la migración .

Si encuentra algún problema de migración, consulte Solución de errores de migración y migración.

Ejecución de una migración

Su equipo ya está listo para comenzar el proceso de ejecución de una migración. Se recomienda empezar con una migración correcta de la ejecución de pruebas antes de intentar una migración de ejecución de producción. Con las importaciones de ejecución de pruebas, puede ver con antelación el aspecto de una migración, identificar posibles problemas y obtener experiencia antes de entrar en la ejecución de producción.

Nota:

  • Si necesita repetir una migración de ejecución de producción completada para una recopilación, como en caso de reversión, póngase en contacto con el servicio de soporte al cliente de Azure DevOps Services antes de poner en cola otra migración.
  • Los administradores de Azure pueden impedir que los usuarios creen nuevas organizaciones de Azure DevOps. Si la directiva de inquilino de Microsoft Entra está activada, la migración no puede finalizar. Antes de comenzar, compruebe que la directiva no está establecida o que hay una excepción para el usuario que realiza la migración. Para obtener más información, consulte Restringir la creación de la organización a través de la directiva de inquilinos de Microsoft Entra.
  • Azure DevOps Services no admite directivas de retención por canalización y no se transfieren a la versión hospedada.

Consideraciones sobre los planes de reversión

Una preocupación común para los equipos que realizan una ejecución de producción final es su plan de reversión, si algo va mal con la migración. Se recomienda encarecidamente realizar una ejecución de prueba para asegurarse de que puede probar la configuración de migración que proporciona a la herramienta de migración de datos para Azure DevOps.

La reversión de la ejecución final de producción es bastante sencilla. Antes de poner en cola la migración, desasocie la colección de proyectos de equipo de Azure DevOps Server, lo que hace que no esté disponible para los miembros del equipo. Si por alguna razón necesita revertir la ejecución de producción y poner el servidor local en línea para los miembros del equipo, puede hacerlo. Adjunte de nuevo la colección de proyectos de equipo local e informe al equipo de que siguen funcionando normalmente mientras el equipo vuelve a agruparse para comprender los posibles errores.

Después, puede ponerse en contacto con el servicio de atención al cliente de Azure DevOps Services para obtener ayuda para comprender la causa del error si no puede determinar la causa. Para obtener más información, consulte el artículo Solución de problemas. Las incidencias de soporte técnico al cliente se pueden abrir desde la página https://aka.ms/AzureDevOpsImportSupportsiguiente. Es importante tener en cuenta que si el problema requiere que los ingenieros del grupo de productos participen en esos casos se controlarán durante el horario comercial normal.

Desasocie la colección de proyectos de equipo de Azure DevOps Server para prepararla para la migración.

Antes de generar una copia de seguridad de la base de datos SQL, la herramienta de migración de datos requiere que la colección se desasocie completamente de Azure DevOps Server (no SQL). El proceso de desasociación de Azure DevOps Server transfiere información de identidad de usuario que se almacena fuera de la base de datos de recopilación y hace que sea portátil para pasar a un nuevo servidor o, en este caso, a Azure DevOps Services.

La desasociación de una colección se realiza fácilmente desde la consola de administración del servidor de Azure DevOps en la instancia de Azure DevOps Server. Para obtener más información, vea Mover colección de proyectos, Desasociar la colección.

Poner en cola la migración

Importante

Antes de continuar, asegúrese de que la colección se desasocia antes de generar un archivo DACPAC o cargar la base de datos de recopilación en una máquina virtual de SQL Azure. Si no completa este paso, se produce un error en la migración. En caso de que se produzca un error en la migración, consulte Resolución de errores de migración.

Inicie una migración mediante el comando import de la Herramienta de migración de datos. El comando de migración toma un archivo de especificación de migración como entrada. Analiza el archivo para asegurarse de que los valores proporcionados son válidos y, si se ejecuta correctamente, pone en cola una migración a Azure DevOps Services. El comando de migración requiere una conexión a Internet, pero no requiere una conexión a la instancia de Azure DevOps Server.

Para empezar, abra una ventana del símbolo del sistema y cambie los directorios a la ruta de acceso a la herramienta de migración de datos. Se recomienda revisar el texto de ayuda proporcionado con la herramienta. Ejecute el siguiente comando para ver las instrucciones y la ayuda para el comando de migración:

Migrator import /help

El comando para poner en cola una migración tiene la estructura siguiente:

Migrator import /importFile:{location of migration specification file}

En el ejemplo siguiente se muestra un comando de migración completado:

Migrator import /importFile:C:\DataMigrationToolFiles\migration.json

Una vez superada la validación, inicie sesión en el identificador de Microsoft Entra con una identidad que sea miembro del mismo inquilino de Microsoft Entra en el que se creó el archivo de registro de mapa de identidad. El usuario que inició sesión es el propietario de la organización importada.

Nota:

Cada inquilino de Microsoft Entra está limitado a cinco importaciones por período de 24 horas. Solo las importaciones que se ponen en cola cuentan con este límite.

Cuando el equipo inicia una migración, se envía una notificación por correo electrónico al usuario que pone en cola la migración. Aproximadamente de 5 a 10 minutos después de poner en cola la migración, el equipo puede ir a la organización para comprobar el estado. Una vez finalizada la migración, el equipo se dirige a iniciar sesión y se envía una notificación por correo electrónico al propietario de la organización.

La herramienta de migración de datos marca los errores que debe corregir antes de la migración. En este artículo se describen las advertencias y errores más comunes que puede recibir al preparar la migración. Después de corregir cada error, vuelva a ejecutar el comando migrator validate para comprobar la resolución.

Pasos siguientes

Resolución de errores de migración