Procesos de validación e importación

Azure DevOps Services | Azure DevOps Server | TFS

Este artículo le guiará a través de la preparación necesaria para obtener una importación a Azure DevOps Services lista para ejecutarse. Si se producen errores durante el proceso, consulte Solución de problemas de importación y migración.

Se recomienda usar la guía de migración paso a paso para avanzar en la importación. La guía incluye vínculos a documentación técnica, herramientas y procedimientos recomendados.

Validación de una colección

Después de confirmar que está ejecutando la versión más reciente de Azure DevOps Server, el siguiente paso es validar cada colección que desea 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.

La validación se ejecuta mediante la herramienta de migración de datos. Para empezar, descargue la herramienta, copie el archivo ZIP en uno de los Azure DevOps Server de aplicación y, a continuación, descomprímalo. También puede ejecutar la herramienta desde otro equipo sin tener Azure DevOps Server instalado siempre y cuando la máquina pueda conectarse a la base de datos de configuración de la Azure DevOps Server instancia. Aquí se muestra un ejemplo.

1. 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. Tómese unos minutos para revisar el contenido de ayuda que se proporciona con 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 
   

2. Dado que esta es la primera vez que valida una colección, vamos a hacerlo sencillo. El comando debe tener la siguiente estructura:

    Migrator validate /collection:{collection URL}
   

   Por ejemplo, para ejecutar en la colección predeterminada, el comando tendría el siguiente aspecto:

    Migrator validate /collection:http://localhost:8080/DefaultCollection
   

3. Para ejecutar la herramienta desde un equipo que no sea el Azure DevOps Server, necesita el parámetro /connectionString. El parámetro de cadena de conexión apunta a la base Azure DevOps Server de datos de configuración. Por ejemplo, si fabrikam corporation ejecuta el comando validate, el comando tendría el siguiente aspecto:

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

   Importante

   La herramienta de migración de datos no edita ningún dato o estructura de la colección. Lee la colección solo para identificar problemas.

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

   

Una vez que se han pasado todas las validaciones, puede ir al siguiente paso del proceso de importación. Si la herramienta de migración de datos marca los errores, debe corregirlos antes de continuar. Para obtener instrucciones sobre cómo corregir errores de validación, consulte Solución de problemas de importación y migración.

Importación de archivos de registro

Al abrir el directorio de registro, observará varios archivos de registro.

El archivo de registro principal se denomina DataMigrationTool.log. Contiene detalles sobre todo lo que se ha ejecutado. 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 Project", puede abrir el archivo ProjectProcessMap.log para ver todo lo que se ha ejecutado para ese paso en lugar de tener que desplazarse por todo el registro.

Debe revisar el archivo TryMatchOobProcesses.log solo si está intentando importar los procesos del proyecto para usar el modelo heredado. Si no desea usar el modelo heredado, puede omitir estos errores, ya que no impedirán la importación a Azure DevOps Services.

Generación de archivos de importación

Por ahora, ha ejecutado la validación de la herramienta de migración de datos en la colección y devuelve un resultado de "Todas las validaciones de recopilación superada". Antes de desconectar una colección para migrarla, debe generar 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 Azure Active Directory (Azure AD).
• import.json:requiere que rellene la especificación de importación que desea usar para iniciar la migración.

El 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 del mapa de identidad,IdentityMapLog.csv, y, a continuación, intenta conectarse a Azure AD para buscar la coincidencia de cada identidad. Para ello, su empresa debe usar la herramienta Azure Active Directory Conectar (anteriormente conocida como herramienta de sincronización de directorios, Directory Sync o DirSync.exe).

Si se configura la sincronización de directorios, la herramienta de migración de datos debe poder encontrar las identidades correspondientes y marcarlas como Activa. Si no encuentra una coincidencia, la identidad se marca como Histórica en el registro del mapa de identidad y deberá investigar por qué el usuario no está incluido 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 comando , requiere una conexión a Internet, ya que debe conectarse a Azure AD para rellenar el archivo de registro del mapa validatepreparevalidate de identidad. Si la Azure DevOps Server no tiene acceso a Internet, debe ejecutar la herramienta desde una máquina que sí lo tenga. 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 prepare el comando , ejecute el siguiente comando:

Migrator prepare /help

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

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 Azure DevOps Server instancia. Por ejemplo, si fabrikam corporation ejecuta el comando, el prepare comando tendría el siguiente aspecto:

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 comando, ejecuta una validación completa para asegurarse de que no ha cambiado nada con la colección desde prepare la última validación completa. Si se detecta algún problema nuevo, no se genera ningún archivo de importación.

Poco después de que el comando haya empezado a ejecutarse, Azure AD ventana de inicio de sesión. Debe iniciar sesión con una identidad que pertenezca al dominio de inquilino especificado en el comando . Asegúrese de que el inquilino Azure AD es con el que desea que se haga una copia de seguridad de su organización futura. En nuestro ejemplo de Fabrikam, un usuario escribiría credenciales similares a las que se muestran en la captura de pantalla siguiente.

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

• import.json es el archivo de especificación de importación. Se recomienda tardar tiempo en rellenarlo.
• IdentityMapLog.csv contiene la asignación generada de Active Directory a Azure AD identidades. Repase la información para ver si es completa antes de iniciar una importación.

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 deseada, la información de la cuenta de almacenamiento y otra información. La mayoría de los campos se repoblan automáticamente y algunos requieren la entrada antes de intentar una importación.

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

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

En la imagen anterior, tenga en cuenta que el planificador de la importación de Fabrikam agregó el nombre de la organización fabrikam-import y seleccionó CUS (Central Estados Unidos) como región para la importación. Otros valores se dejaron tal y como se deben modificar justo antes de que el planificador dejara sin conexión la colección para la migración.

Regiones de Azure admitidas para la importación

Azure DevOps Services está disponible en varias regiones de Azure. Sin embargo, no todas las regiones donde Azure DevOps Services están disponibles se admiten para la importación. En la tabla siguiente se enumeran las regiones 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 región para la importación.

El registro del mapa de identidad

El registro del mapa de identidad tiene la misma importancia que los datos reales que va a migrar a Azure DevOps Services. Al revisar el archivo, es importante comprender cómo funciona la importación de identidades y lo que podrían conllevar los posibles resultados. Al importar una identidad, puede convertirse en activa ohistórica. Las identidades activas pueden iniciar sesión en Azure DevOps Services, pero las identidades históricas no.

Identidades activas

Las identidades activas hacen referencia a las identidades que serán usuarios 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 del archivo de registro del mapa de identidad.

Identidades históricas

Las identidades históricas se asignan como tales en la columna Estado de importación esperado del archivo de registro del mapa de identidad. Las identidades sin una entrada de línea en el archivo también se convierten en históricas. Un ejemplo de una 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 tiene licencias.
• No se muestren como usuarios de la organización. Lo único que persiste es la noción del nombre de esa identidad en la organización, para 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.

Información sobre el archivo de registro del mapa de identidad

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

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

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 se espera que la identidad de esta fila se asigne correctamente al importar y se active. Histórico significa que las identidades se convertirán en históricas en la importación. Es importante revisar el archivo de asignación generado para ver si es correcto y completo.

1. Empiece por revisar las identidades coincidentes correctamente. ¿Están presentes todas las identidades esperadas? ¿Los usuarios están asignados a la identidad Azure AD correcta?

   Si algún valor está asignado incorrectamente o necesita cambiarse, póngase en contacto con el administrador de Azure AD para comprobar que la identidad de Active Directory local forma parte de la sincronización con Azure AD y se ha configurado correctamente. Para obtener más información, consulte Integración de las identidades locales con Azure Active Directory.

2. A continuación, revise las identidades etiquetadas como históricas. Este etiquetado implica que no se pudo encontrar una identidad Azure AD coincidencia, por cualquiera de los siguientes motivos:

   • La identidad no se ha configurado para la sincronización entre Active Directory local y Azure AD.
   • La identidad aún no se ha rellenado en la Azure AD (por ejemplo, hay un nuevo empleado).
   • La identidad no existe en la instancia Azure AD usuario.
   • El usuario propietario de esa identidad ya no trabaja en la empresa.

Para solucionar los tres primeros motivos, debe configurar la identidad de Active Directory local que se va a sincronizar con Azure AD. Para obtener más información, consulte Integración de las identidades locales con Azure Active Directory. Debe configurar y ejecutar las Azure AD Conectar identidades que se importarán como activas en Azure DevOps Services.

Puede omitir la cuarta razón, ya que los empleados que ya no están en la empresa deben importarse como históricos.

Identidades históricas (equipos pequeños)

Si Azure AD Conectar no se ha configurado, observará que todos los usuarios del archivo de registro del mapa de identidad están marcados como históricos. Al ejecutar una importación de este modo, todos los usuarios se importan como históricos. Se recomienda encarecidamente configurar los Azure AD 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 considerarse cuidadosamente. Solo lo deben tener en cuenta los equipos con un pequeño número de usuarios y para los que el costo de configurar Azure AD 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 que se usa para poner en cola la importación se arranca en la organización como el propietario de la organización. Todos los demás usuarios se importan como históricos. A continuación, los propietarios de la organización pueden volver a agregar los usuarios mediante su Azure AD identidad. Los usuarios agregados se tratan como nuevos usuarios. No poseen ninguno de sus historiales y no hay ninguna manera de volver a convertir este historial en la Azure AD identidad. Sin embargo, los usuarios todavía pueden buscar su historial previo a la importación buscando su dominio < Active Directory nombre de usuario ><> .

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

Suscripciones de Visual Studio

La herramienta de migración de datos no puede detectar Visual Studio suscripciones (anteriormente conocidas como ventajas de MSDN) cuando genera el archivo de registro del 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 suscripción de Visual Studio en su primer inicio de sesión después de la importación. Nunca se le cobrará por las licencias asignadas durante la importación, por lo que esto se puede controlar de forma segura después.

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

Preparación para la importación

Ya tiene todo listo para ejecutarse en la importación. Debe programar el tiempo de inactividad con su equipo para desconectar la recopilación para la migración. Cuando haya acordado un momento para ejecutar la importación, debe cargar en Azure los recursos necesarios que ha generado y una copia de la base de datos. Este proceso tiene cinco pasos:

Paso 1: Desconectar la colección y separarla.

Paso 2: Generar un archivo DACPAC a partir de la colección que va a importar.
Paso 3: Upload el archivo DACPAC e importar archivos a una cuenta de Almacenamiento de Azure.
Paso 4: Generación de una clave SAS para la cuenta de almacenamiento.
Paso 5: Completar la especificación de importación.

Paso 1: Desasoción de la colección

La desasoción de 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 Azure DevOps Server de configuración de la instancia mientras la colección está adjunta y en línea. Cuando una colección se desasocia de la Azure DevOps Server, toma una copia de los datos de identidad y los empaqueta con la colección para su transporte. Sin estos datos, no se puede ejecutar la parte de identidad de la importación. Se recomienda mantener desasociada la colección hasta que se haya completado la importación, ya que no hay ninguna manera de importar los cambios que se produjeron durante la importación.

Si va a realizar una importación de dry run (prueba), se recomienda que vuelva a asociar la colección después de realizar la copia de seguridad para la importación, ya que no le preocupará 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 una desasoción sin conexión para los dry runs.

Es importante sopesar el costo de elegir incurrir en un tiempo de inactividad cero para un "dry run". Requiere realizar copias de seguridad de la base de datos de recopilación y 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 tardar solo unas horas de tiempo de inactividad para realizar directamente la copia de seguridad desasociada es mejor a largo plazo.

Paso 2: Generar un archivo DACPAC

Las 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 empiezan a disminuir.

DACPAC es una característica de SQL que permite empaquetar los cambios de base de datos en un único archivo e implementarse en otras instancias de SQL. 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. Use la herramienta SqlPackage.exe para generar el archivo DACPAC. La herramienta se incluye como parte de SQL Server Data Tools (SSDT).

Varias versiones de la SqlPackage.exe se instalan con SSDT. Las versiones se almacenan en carpetas con nombres como 120, 130 y 140. Al usar SqlPackage.exe, es importante usar la versión correcta para preparar el DACPAC.

• Las importaciones de TFS 2018 deben usar la SqlPackage.exe de la carpeta 140 o superior.

Si ha instalado SSDT para Visual Studio, encontrará la versión de SqlPackage.exe en una de las siguientes rutas de acceso de carpeta:

• Si ha instalado SSDT y lo ha integrado con una instalación existente de Visual Studio, la ruta de acceso SqlPackage.exe carpeta es similar a C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130\ .
• Si instaló SSDT como una instalación independiente, la ruta de acceso SqlPackage.exe carpeta es similar a C:\Program Files (x86)\Microsoft Visual. Studio\2017\SQL\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130\ .
• Si ya tiene una instalación de SQL Server, SqlPackage.exe ya está presente y la ruta de acceso de la carpeta es similar a %PROGRAMFILES%\Microsoft SQL Server\130\DAC\bin\ .

Ambas versiones de SSDT que puede descargar de SQL Server Data Tools incluyen las carpetas 130 y 140 y sus SqlPackage.exe versiones.

Al generar un DACPAC, tenga en cuenta dos consideraciones: el disco en el que se guardará 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 datos de la colección en el directorio temporal en la unidad C de la máquina desde la que se inicia 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 necesitará buscando la tabla más grande de la base de datos de colección. Las DACPA 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 va a guardar el DACPAC generado en la unidad C, también debe tener en cuenta el tamaño de la base de datos de recopilación, tal como se muestra en el archivo DataMigrationTool.log de 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 validate. Para obtener un ejemplo de tamaños de tabla para una colección, vea 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.

[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 mucho más largos. Si una unidad rápida como una unidad de estado sólido (SSD) está disponible localmente, se recomienda que la unidad tenga como destino la ubicación de almacenamiento de DACPAC. De lo contrario, siempre es más rápido usar un disco que se encuentra en la máquina donde reside la base de datos de recopilación en lugar de una unidad remota.

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

Abra una ventana del símbolo del sistema y vaya a SqlPackage.exe ubicación. 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:la SQL Server que hospeda la base de Azure DevOps Server de datos.
• Catálogo inicial:el nombre de la base de datos de colección.
• targetFile:la ubicación en el disco y el nombre de archivo DACPAC.

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

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 que se genera a partir de la base de datos de colección Foo denominada Foo.dacpac.

Configuración de la colección para la importación

Una vez restaurada la base de datos de recopilación en la máquina virtual de Azure, configure un inicio de sesión de SQL para permitir Azure DevOps Services conectarse 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 SQL inicio de sesión 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 SQL comandos tendrían un aspecto parecido al 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'

Configuración del archivo de especificación de importación para dirigirse a la máquina virtual

Actualice el archivo de especificación de importación para incluir información sobre cómo conectarse a la instancia SQL Server importación. 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:

   

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

   

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

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

Siguiendo el ejemplo de Fabrikam, después de aplicar los cambios, la especificación de importación tendría el siguiente aspecto:

La especificación de importación ahora está configurada para usar una máquina SQL Azure virtual 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 SQL inicio de sesión o rotar la contraseña. Microsoft no conserva la información de inicio de sesión una vez finalizada la importación.

Paso 3: Upload el archivo DACPAC

El DACPAC debe colocarse en un contenedor de almacenamiento de Azure. Puede ser un contenedor existente o uno creado específicamente para el trabajo de migración. Es importante asegurarse de que el contenedor se crea en la región correcta.

Azure DevOps Services está disponible en varias regiones. Al importar a estas regiones, es fundamental colocar los datos en la región correcta para asegurarse de que la importación se puede iniciar correctamente. Los datos deben colocarse en la misma región a la que se va a importar. Si coloca los datos en cualquier otro lugar, la importación no se podrá iniciar. En la tabla siguiente se enumeran las regiones aceptables para crear la cuenta de almacenamiento y cargar los datos.

Aunque Azure DevOps Services está disponible en varias regiones de EE. UU., solo la región Central Estados Unidos acepta nuevas Azure DevOps Services. En este momento no puede importar los datos a otras regiones de Azure de EE. UU.

Puede crear un contenedor de blobs desde el Azure Portal. Después de crear el contenedor, debe cargar el archivo DACPAC de colección.

Una vez finalizada la importación, puede eliminar el contenedor de blobs y la cuenta de almacenamiento que lo acompaña. Para ello, puede usar herramientas como AzCopy o cualquier otra herramienta del explorador de Azure Storage, como Explorador de Azure Storage.

Paso 4: Generación de una clave SAS

Una clave de firma de acceso compartido (SAS) proporciona acceso delegado a los recursos de una cuenta de almacenamiento. La clave le permite proporcionar a Microsoft el nivel más bajo de privilegios necesarios para acceder a los datos para ejecutar la importación.

La manera recomendada de generar una clave SAS es usar Explorador de Azure Storage. Con Explorador de Storage, puede crear fácilmente claves SAS de nivel de contenedor. Esto es esencial, ya que la herramienta de migración de datos no admite claves SAS de nivel de cuenta.

Después de instalar Explorador de Storage, puede generar una clave SAS haciendo lo siguiente:

1. Abra el Explorador de Storage.

2. Agregue una cuenta.

3. Seleccione Use a storage account name and key (Usarun nombre de cuenta de almacenamiento y una clave) y, a continuación, Conectar.

   

4. En el panel Adjuntar Storage externo, escriba el nombre de la cuenta de almacenamiento, proporcione una de las dos claves de acceso principales y, a continuación, seleccione Conectar.

   

5. En el panel izquierdo, expanda Contenedores de blobs,haga clic con el botón derecho en el contenedor que almacena los archivos de importación y, a continuación, seleccione Obtener firma de acceso compartido.

   

6. Para La hora de expiración, establezca la fecha de expiración para siete días en el futuro.

   

7. En Permisos para la clave SAS, active las casillas Leer y Enumerar. No se requieren permisos de escritura y eliminación.

   Nota

   • Copie y almacene esta clave SAS para colocarla en el archivo de especificación de importación en el paso siguiente.
   • Trate esta clave SAS como un secreto. Proporciona acceso a los archivos en el contenedor de almacenamiento.

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

Anteriormente en el proceso, ha rellenado parcialmente el archivo de especificación de importación conocido normalmente 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 tratará 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, copió 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.

Con el ejemplo de Fabrikam, el archivo de especificación de importación final debe tener un aspecto parecido al siguiente:

Restringir el acceso a Azure DevOps Services solo ips

Se recomienda encarecidamente restringir el acceso a la cuenta Azure Storage solo a las ips de Azure DevOps Services. Para ello, permita conexiones solo desde el conjunto de Azure DevOps Services ip que intervienen en el proceso de importación de la base de datos de recopilación. Las IP a las que se debe conceder acceso a la cuenta de almacenamiento dependen de la región en la que se va a importar. Use la opción IpList para obtener la lista de direcciones IP a las que se debe conceder acceso.

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

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

Determinación del tipo de importación

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

• DryRun:use un dry run con fines de prueba. El sistema elimina los sesos 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 que finalice la importación.

Organizaciones de ejecución en dry-run

Las importaciones de ejecución sin problemas ayudan a los equipos a probar la migración de sus colecciones. Se espera que las organizaciones no permanezcan indefinidamente, sino que existan durante un breve período de tiempo. De hecho, antes de que se pueda ejecutar una migración de producción, es necesario eliminar todas las organizaciones de dry-run completadas. Todas las organizaciones de ejecución continua 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 eliminará la organización se incluye en el correo electrónico correcto que debe recibir una vez que finalice la importación. Asegúrese de tomar nota de esta fecha y planear en consecuencia.

La mayoría de las organizaciones de ejecución en seque tienen 15 días antes de que se eliminen. Las organizaciones de ejecución sin sistema pueden tener también una expiración de 21 días si más de 100 usuarios tienen una licencia básica o superior en el momento de la importación. Después del período de tiempo especificado, se elimina la organización de dry-run. Puede repetir las importaciones de ejecución continua tantas veces como necesite antes de realizar una migración de producción. Debe eliminar los sesos anteriores antes de intentar uno nuevo. Cuando el equipo esté listo para realizar una migración de producción, deberá eliminar manualmente la organización de dry-run.

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

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

Ejecución de una importación

El equipo ya está listo para comenzar el proceso de ejecución de una importación. Se recomienda comenzar con una importación de dry-run correcta antes de intentar una importación de ejecución de producción. Con las importaciones de "dry-run", puede ver de antemano cómo se verá una importación, identificar posibles problemas y obtener experiencia antes de dirigirse a la ejecución de producción.

Consideraciones sobre los planes de reversión

Una preocupación común para los equipos que están realizando una ejecución de producción final es cuál será su plan de reversión si algo va mal con la importación. Este es el motivo por el que se recomienda encarecidamente realizar un "dry run" 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 para la ejecución final de producción es bastante sencilla. Antes de poner en cola la importación, desasoja la colección de proyectos de equipo de Azure DevOps Server o Team Foundation Server, lo que hará que no esté disponible para los miembros del equipo. Si por algún motivo necesita revertir la ejecución de producción y volver a poner el servidor local en línea para los miembros del equipo, puede hacerlo. Simplemente adjunte de nuevo la colección de proyectos de equipo localmente e informe al equipo de que seguirán funcionando con normalidad mientras el equipo se reagrupa para comprender los posibles errores.

Poner en cola una importación

Para iniciar una importación, use 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 realiza correctamente, pone en cola una importación para Azure DevOps Services. El comando import requiere una conexión a Internet, pero no requiere una conexión a Azure DevOps Server instancia.

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 tardar un momento en revisar el texto de ayuda proporcionado con la herramienta. Ejecute el siguiente comando para ver las instrucciones y la ayuda del comando de importación:

Migrator import /help

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

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

Este es un ejemplo de un comando de importación completado:

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

Una vez que se supera la validación, se le pedirá que inicie sesión en Azure AD. Es importante iniciar sesión con una identidad que sea miembro del mismo inquilino Azure AD que se comcreó el archivo de registro del mapa de identidad. El usuario que inicia sesión se convierte en el propietario de la organización importada.

Cuando el equipo inicia una importación, se envía una notificación por correo electrónico al usuario que puso 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 que finalice la importación, se dirigirá al equipo para que inicie sesión y se enviará una notificación por correo electrónico al propietario de la organización.

Artículos relacionados

• Migrar opciones
• Posterior a la importación