Procesos de validación e importación

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

En este artículo se explica la preparación necesaria para obtener una importación a Azure DevOps Services lista para ejecutarse. Si encuentra errores durante el proceso, consulte Solución de problemas de importación y migración.

Requisitos previos

  • Debe configurar un inquilino de Microsoft Entra como se describe en Microsoft Entra Conectar Sync: Realizar un cambio en la configuración predeterminada. La herramienta de migración de datos configura un vínculo al inquilino de Microsoft Entra cuando se crea la organización de Azure DevOps Services como parte del principio del proceso de importación. Al sincronizar el Active Directory local con el identificador de Microsoft Entra, los miembros del equipo pueden usar las mismas credenciales para autenticarse y los administradores de Azure DevOps Services pueden usar los grupos de Active Directory para establecer permisos en la organización de Azure DevOps Services. Para configurar la sincronización, use la tecnología Microsoft Entra Conectar.
  • Antes de comenzar las tareas de importación, compruebe que está ejecutando una versión compatible de Azure DevOps Server.
  • Se recomienda usar la guía de migración paso a paso para avanzar a través de la importación. En la guía se incluyen vínculos a documentación técnica, herramientas y procedimientos recomendados.

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. Descarga de la herramienta

  2. Copia del 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 la primera vez que valida una colección, vamos a simplificarla. El comando debe tener la estructura siguiente:

     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 le gustaría el ejemplo:

     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 siguiente 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 en 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 paso siguiente del proceso de importació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 errores de importación y 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 importar 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.

Generación de archivos de importación

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

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

Comando Prepare

El prepare comando ayuda a generar los archivos de importació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 Conectar (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 importación, import.json, debe rellenarse antes de la importación.

A diferencia del validate comando , preparerequiere 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 recopilación desde la última validación completa. Si se detectan problemas nuevos, no se generan archivos de importació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 importació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 importación de identidades al iniciar la ejecución de producción con el inquilino de Producción de Microsoft Entra de la organización.

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

  • import.json es el archivo de especificación de importación. Le recomendamos que dedique tiempo a rellenarlo.
  • IdentityMapLog.csv contiene la asignación generada de Active Directory a identidades de Microsoft Entra. Después de iniciar una importación, resólela por completo.

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

Archivo de especificación de importación

La especificación de importación, import.json, es un archivo JSON que proporciona la configuración de importació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 importación.

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

Los campos mostrados y las acciones necesarias del archivo import.json 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 importació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 importació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 importació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 en la que se va a importar. 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 importación. Proporcione un nombre. El nombre se puede cambiar rápidamente después de que se complete la importación.
NOTA: No cree una organización con este nombre antes de ejecutar la importación. La organización se crea como parte del proceso de importación.
ImportType Tipo de importación que desea ejecutar. No es necesaria ninguna acción. En un paso posterior, seleccione el tipo de importación que se va a ejecutar.
Datos de validación Información necesaria para ayudar a impulsar la experiencia de importación. La herramienta de migración de datos genera la sección "ValidationData". Contiene información para ayudar a impulsar la experiencia de importación. No edite los valores de esta sección o la importació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 importación completado parcialmente.

En la imagen anterior, el planificador de la importación de Fabrikam agregó el nombre de organización fabrikam-import y cuS seleccionado (Central Estados Unidos) como ubicación geográfica para la importació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 seca tienen un "-dryrun" anexado automáticamente al final del nombre de la organización, que puede cambiar después de la importación.

Ubicaciones geográficas de Azure admitidas para la importació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 importación. En la tabla siguiente se enumeran las ubicaciones geográficas de Azure que puede seleccionar para la importación. También se incluye el valor que debe colocar en el archivo de especificación de importación para dirigirse a esa geografía para la importació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 revisa el archivo, es importante comprender cómo funciona la importación de identidades y cuáles podrían implicar los posibles resultados. Al importar 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 importació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 el 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 microsoft Entra Conectar Sync.

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 que se encuentra pronto a estar activo o No Match Found (Comprobar sincronización de id. de Entra de Microsoft), que indica que la identidad no se encuentra durante la sincronización de identificadores de Entra de Microsoft y se importa como histórica.
Estado de importación esperado El estado de importació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 al importar se activa. Histórico significa que las identidades se convierten en históricas en la importación. Es importante revisar el archivo de asignación generado para que sea completo y correcto.

Importante

Se produce un error en la importación si se producen cambios importantes en la sincronización del identificador de seguridad de Microsoft Entra Conectar entre los intentos de importación. Puede agregar nuevos usuarios entre ejecuciones secas y realizar correcciones para asegurarse de que las identidades históricas importadas previamente estén activas. Sin embargo, no se admite el cambio de un usuario existente que se importó previamente como activo en este momento. Si lo hace, se producirá un error en la importación. Un ejemplo de un cambio podría estar completando una importación de ejecución seca, eliminando una identidad del identificador de Microsoft Entra que se importó activamente, volver a crear un nuevo usuario en Microsoft Entra ID para esa misma identidad y, a continuación, intentar otra importación. En este caso, una identidad activa intenta importar entre Active Directory y la identidad de Microsoft Entra recién creada, pero produce un error de importació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 está configurada 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 Conectar 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 importación de identidades propuesta en esta sección.

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

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

Para importar todas las identidades como históricas, siga los pasos descritos en secciones posteriores. Al poner en cola una importación, la identidad usada para poner en cola la importació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 preimportar buscando su <nombre de usuario de Active Directory de> dominio><.

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 identidad. En su lugar, se recomienda aplicar la característica de actualización automática de licencias después de la importació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 importación. Nunca se le cobrarán las licencias que se asignan durante la importación, por lo que puede controlar de forma segura las suscripciones después.

No es necesario repetir una importación de ejecución seca 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 importación. Siempre que su cuenta profesional esté vinculada correctamente antes o después de la importació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 importación, los usuarios se actualizarán automáticamente en su primer inicio de sesión a la organización.

Preparación para la importación

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

Paso 1: Desconectar la colección y desasociarla.

El límite de tamaño de colección para el método DACPAC es de 150 GB. Si la herramienta de migración de datos muestra una advertencia de que no puede usar el método DACPAC, debe realizar la importación mediante el método SQL Azure máquina virtual (VM). Omita los pasos 2 a 5 en ese caso y siga las instrucciones proporcionadas en Importación de colecciones grandes y, a continuación, continúe con la sección determinar el tipo de importación.

Paso 2: Generar un archivo DACPAC a partir de la colección que va a importar.
Paso 3: Cargar el archivo DACPAC e importar archivos 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 importación.

Nota

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

Paso 1: Desasociar la colección

Desasociar la colección es un paso fundamental en el proceso de importació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 importación. Se recomienda mantener la colección desasociada hasta que se complete la importación, ya que no hay una manera de importar los cambios que se produjeron durante la importación.

Para una importación de ejecución seca (prueba), se recomienda volver a adjuntar la colección después de realizar una copia de seguridad para la importación, por lo que no le preocupa tener los datos más recientes para este tipo de importación. Para evitar el tiempo sin conexión por completo, también puede optar por emplear un desasocio sin conexión para las ejecuciones secas.

Es importante ponderar el costo de elegir incurrir en un tiempo de inactividad cero para una carrera seca. 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 de que no puede usar el método DACPAC, debe realizar la importación mediante el método SQL Azure máquina virtual (VM) proporcionado en Importar colecciones grandes.

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 de guardado 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 colección para la importación

Después de restaurar la base de datos de recopilación 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 importar 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 [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'

Nota:

Asegúrese de habilitar el modo de SQL Server y 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 importación.

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

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

  1. Quite el parámetro DACPAC del objeto de archivos de origen.

    La especificación de importación antes del cambio se muestra en el código siguiente.

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

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

    Captura de pantalla de la especificación de importació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 importación es similar al ejemplo siguiente.

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

La especificación de importación ahora está configurada para usar una máquina virtual de SQL Azure para la importación. Continúe con el resto de los pasos de preparación para importar a Azure DevOps Services. Una vez finalizada la importació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 importació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 importació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 importació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 importació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 importar los datos en otras ubicaciones de Azure de EE. UU. en este momento.

Puede crear un contenedor de blobs a partir del Azure Portal. Después de crear el contenedor, cargue el archivo DACPAC de colección.

Una vez finalizada la importación, elimine el contenedor de blobs y la cuenta de almacenamiento que 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 importación.

Los tokens de SAS se pueden generar mediante Azure Portal. Desde un punto de vista de seguridad, se recomienda:

  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. Coloque el token de SAS en una ubicación segura.

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

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

En el archivo de especificación import.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 importación final debe tener un aspecto similar al del ejemplo siguiente.

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

Restringir el acceso solo a direcciones IP de Azure DevOps Services

Para más información, consulte Restringir el acceso solo a direcciones IP de Azure DevOps Services.

Opción 1: Usar etiquetas de servicio

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

Opción 2: Usar IpList

Use el IpList comando para obtener la lista de direcciones IP a las que se debe conceder acceso para permitir conexiones desde una ubicación geográfica 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.

Determinación del tipo de importación

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

  • DryRun: use una serie seca con fines de prueba. El sistema elimina las ejecuciones secas después de 21 días.
  • ProductionRun: use una ejecución de producción cuando desee mantener la importación resultante y usar la organización a tiempo completo en Azure DevOps Services una vez finalizada la importación.

Sugerencia

Siempre se recomienda completar primero una importación de ejecución seca.

Archivo de especificación de importación completado con el tipo de importación

Organizaciones de ejecución en seco

Las importaciones de ejecución en seco ayudan a los equipos a probar la migración de sus colecciones. Se espera que las organizaciones no permanezcan para siempre, sino que existan durante un breve tiempo. De hecho, antes de que se pueda ejecutar una migración de producción, se deben eliminar todas las organizaciones de ejecución seca completadas. Todas las organizaciones de ejecución seca 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 importación. Asegúrese de tomar nota de esta fecha y planear en consecuencia.

La mayoría de las organizaciones de ejecución seca tienen 15 días antes de que se eliminen. Las organizaciones de ejecución en seco también pueden tener una expiración de 21 días si más de 100 usuarios tienen una licencia básica o mayor en el momento de la importación. Después del período de tiempo especificado, se elimina la organización de la ejecución en seco. Puede repetir las importaciones de seco tantas veces como necesite antes de realizar una migración de producción. Debe eliminar las ejecuciones secas 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 seca.

Para obtener más información sobre las actividades posteriores a la importación , consulte el artículo posterior a la importación.

Si tiene algún problema de importación, consulte Solución de problemas de importación y migración.

Ejecución de una importación

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

Nota:

  • Si necesita repetir una importación de ejecución de producción completada para una recopilación, como en caso de una reversión, póngase en contacto con Azure DevOps Services soporte técnico al cliente antes de poner en cola otra importació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 importació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 importación. Se recomienda encarecidamente realizar una ejecución en seco para asegurarse de que puede probar la configuración de importació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 importació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.

Poner en cola una importació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 producirá un error en la importación. En caso de que se produzca un error en la importación, consulte Solución de errores de importación y migración.

Inicie una importación mediante el comando import de la herramienta de migración de datos. El comando import toma un archivo de especificación de importació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 importación a Azure DevOps Services. El comando import 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 del comando import:

Migrator import /help

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

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

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

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

Una vez superada la validación, se le pedirá que inicie sesión en el identificador de Microsoft Entra. Es importante iniciar sesión 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 importación, se envía una notificación por correo electrónico al usuario que pone en cola la importación. Aproximadamente entre 5 y 10 minutos después de poner en cola la importación, el equipo puede ir a la organización para comprobar el estado. Una vez finalizada la importació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.