Traslado o clonación de un hardware a otro para Azure DevOps local

  • Artículo

Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019

Puede mover o clonar la implementación de Azure DevOps Server software. Se mueve Azure DevOps Server de una máquina a otra mediante la restauración a un nuevo hardware (denominado movimiento basado en restauración). Por ejemplo, es posible que desee mover Azure DevOps Server a un servidor con mayor capacidad o mayor velocidad de procesamiento. Cuando se mueve a un nuevo servidor, no se pierde ninguno del historial de proyectos.

Para clonar la implementación de Azure DevOps Server, realice los mismos pasos que un traslado más algunos adicionales.

Realice un traslado cuando planee interrumpir el uso del hardware original y Azure DevOps Server implementación. Realice un clon cuando quiera seguir usando la instancia de Azure DevOps Server original.

Importante

En algunas situaciones, es posible que desee cambiar el dominio de una implementación de Azure DevOps Server, así como su hardware. El cambio de dominio es un movimiento basado en el entorno y nunca deben combinarse ambos tipos de movimiento. Complete primero el movimiento de hardware y después cambie el entorno.

Comprobar los permisos

Para mover correctamente Azure DevOps Server, deberá ser administrador en ambos conjuntos de hardware (el antiguo y el nuevo). Además, deberá ser administrador (o tener los permisos equivalentes) para Azure DevOps Server y todo el software en el que depende la implementación: SQL Server, informes y cualquier otro software con el que la implementación interopera, como Project Server.

Asegúrese de que es miembro de los siguientes grupos:

  • Servidores: Administradores (grupo Administradores local o equivalente)
  • Azure DevOps Server: Administradores de Team Foundation y usuarios de la consola de Administración
  • SQL Server: sysadmin

Si no es miembro de uno o varios de estos grupos, obtenga permisos ahora.

Copia de seguridad de bases de datos y clave de cifrado

  1. Abra la consola de administración para Azure DevOps Server y, en la página Copias de seguridad programadas, realice una copia de seguridad completa. La copia de seguridad realizará una copia de todos los valores configurados para esta en el plan de copia de seguridad, pero lo hará inmediatamente, no según la hora programada en el plan. Si la implementación usa informes, puede realizar copias de seguridad de la clave de cifrado como parte de este conjunto de copias de seguridad.

    Puede cerrar la ventana mientras se completa el trabajo

    (Si no tiene copias de seguridad configuradas, tendrá que crear un plan para poder realizar una copia de seguridad completa).

  2. Una vez completada la copia de seguridad, compruebe que esté disponible en el dispositivo de almacenamiento o el recurso compartido de red y que puede tener acceso a ella desde el nuevo hardware.

Instalar y configurar SQL Server en el nuevo servidor de capa de datos

  • Instale SQL Server en el nuevo servidor y asegúrese de que está operativo. Si la implementación anterior usaba informes, asegúrese de incluir los componentes Reporting Services y Analysis Services. Debe instalar la misma versión y edición que usó anteriormente, incluido el Service Pack y los niveles de actualización acumulativa.

    Instalar SQL Server 2008 R2: características

    Como alternativa, puede crear una instancia de SQL Server en un servidor que ya tenga instalada una versión coincidente y restaurar las bases de datos de Azure DevOps Server en esa instancia, pero que requerirán más configuración posterior a la restauración.

    Para obtener más información sobre las opciones para instalar y configurar SQL Server, vaya aquí.

    Después de instalar SQL Server, si la implementación incluye informes, abra SQL Server Management Studio y desasocie las bases de datos ReportServer y ReportServerTempDB. De lo contrario, es posible que no pueda restaurar estas bases de datos con la copia de seguridad que creó para las bases de datos de Azure DevOps Server.

    Las bases de datos existentes deben desasociarse antes de restaurar

Instalar y configurar software en el nuevo servidor de capa de aplicación

Para configurar un nuevo servidor o servidores para Azure DevOps Server, primero debe instalar y configurar el software necesario para admitirlo. Este software incluye los componentes siguientes:

  • un sistema operativo compatible para su configuración de implementación

  • Instale y configure Windows, IIS (si no está configurado de forma predeterminada) y asegúrese de que el servidor y su software estén operativos. 

    Para obtener más información, consulte los requisitos del sistema para Azure DevOps Server.

Restauración de las bases de datos de Azure DevOps Server

Para restaurar las bases de datos de Azure DevOps Server mediante la herramienta de restauración, debe instalar pero no configurar Azure DevOps Server en el nuevo servidor de capa de datos y, a continuación, usar la función restore en el nodo Copias de seguridad programadas.

Si desea restaurar Azure DevOps Server bases de datos manualmente mediante SQL Server herramientas de restauración, puede hacerlo, pero es un procedimiento más difícil. Además, tendrá que desactivar manualmente el modo inactivo de las bases de datos en la nueva implementación. El asistente para restaurar de Azure DevOps Server lo hace automáticamente como parte de su proceso de restauración, pero esa funcionalidad no forma parte de las herramientas de restauración de SQL Server.

  1. Inicie los medios de instalación de Azure DevOps Server. En la página Configuración de Team Foundation Server , elija Instalar.

  2. Cuando se complete la instalación, se abrirá el Centro de configuración de Team Foundation Server . Ciérrelo.

    La consola de administración se abre automáticamente en un estado no configurado. Se espera que esto sea así.

  3. Para iniciar el Asistente para restaurar, abra la consola de administración para Azure DevOps Server y abra Copias de seguridad programadas.

    Iniciar el asistente para restaurar

  4. Especifique la ruta de acceso al conjunto de copias de seguridad y elija el conjunto que creó tras poner la implementación anterior en modo inactivo.

    Elegir la ruta de acceso de red y, a continuación, el conjunto para restaurar

  5. Finalice el asistente y restaure las bases de datos en la nueva instancia de SQL Server.

    Las bases de datos se restauran en el nuevo servidor

(Opción de clonación) Reconfiguración de las id. del servidor y reasignar las bases de datos

Nota

PrepareClone solía recomendarse para su uso antes de levantar una nueva implementación de Azure DevOps Server mediante una copia de seguridad de base de datos ya en producción en otro servidor. Este comando ya no es necesario, ya que incorporamos su funcionalidad en los escenarios de actualización y clonación de preproducción en el Asistente para configuración.

Realice el siguiente conjunto de pasos en el nuevo servidor de nivel de aplicación si piensa seguir usando la instancia de Azure DevOps Server original. Estos pasos son necesarios para evitar el riesgo de daños en una o ambas implementaciones. Si ambos servidores están activos, podría acabar con daños, especialmente si apuntan a los mismos recursos de informes.

  1. Abra una ventana del símbolo del sistema como administrador y cambie los directorios a Unidad:%programfiles%\TFS 12.0\Tools. Abra una ventana de símbolo del sistema y escriba:

  2. Ejecute el comando TFSConfig PrepareClone para quitar información sobre las copias de seguridad programadas y los recursos de informes.

    TFSConfig PrepareClone /SQLInstance:ServerName /DatabaseName:DatabaseName /notificationURL: ApplicationTierURL

  3. Ejecute el comando TFSConfig ChangeServerID para cambiar los GUID de servidor asociados a las bases de datos. Los GUID deben ser únicos en Azure DevOps Server implementación.

    TFSConfig ChangeServerID /SQLInstance:ServerName] /DatabaseName:ConfigurationDatabaseName [/ProjectCollectionsOnly] [/ConfigDBOnly] [/usesqlalwayson]

  4. Ejecute el comando RemapDBs tfSConfig para redirigir el Azure DevOps Server clonado a sus bases de datos.

    TFSConfig RemapDBs /DatabaseName:ServerName;DatabaseName /SQLInstances:ServerName1,erverName2 [/AnalysisInstance:ServerName] [/AnalysisDatabaseName:DatabaseName] [/review] [/continue] [/usesqlalwayson]

Configuración del servidor de nivel de aplicación

  1. En la consola de administración de Azure DevOps Server, elija Configurar características instaladas para iniciar el centro de configuración.

  2. Inicie el asistente Solo Application-Tier y, en Bases de datos, especifique la nueva instancia de SQL Server donde restauró las bases de datos de Azure DevOps Server. En la lista, elija la base de datos Tfs_Configuration.

    Seleccionar la instancia de SQL Server y el conjunto de copias de seguridad de bases de datos

  3. Antes de cerrar la última página del asistente, busque el símbolo "i". Se trata de información que puede necesitar para consultas posteriores. La última página también incluye la ubicación del registro de configuración.

    Anotar cualquier problema y la ubicación del archivo de registro

Actualizar direcciones URL de Azure DevOps Server

  1. Vaya al nodo de capa de aplicación y examine la notificación y las direcciones URL del portal web. Observe que todavía señalan a la ubicación de la implementación anterior. Actualícelas.

    Las direcciones URL de notificación y de web están obsoletas

  2. Después de actualizar las direcciones URL con el nombre del nuevo servidor, revise la información para asegurarse de que es correcta.

    La dirección URL de servidor sigue usando localhost

Actualizar todas las cuentas de servicio

Debe actualizar la cuenta de servicio para Azure DevOps Server (TFSService) y la cuenta de orígenes de datos (TFSReports). Aunque estas cuentas no hayan cambiado, debe actualizar la información para ayudar a asegurarse de que la identidad y el formato de las cuentas sean adecuados para el nuevo servidor.

  1. Abra una ventana del símbolo del sistema como administrador y cambie los directorios a Unidad:\%programfiles%\TFS 12.0\Tools.

  2. En el símbolo del sistema, escriba el siguiente comando para agregar la cuenta de servicio para Azure DevOps, donde DatabaseName es el nombre de la base de datos de configuración (de forma predeterminada, TFS_Configuration):

    Cuentas tfsConfig /add /AccountType:ApplicationTier /account:AccountName/SQLInstance:ServerName/DatabaseName:DatabaseName

  3. En el símbolo del sistema, escriba el siguiente comando para agregar la cuenta de origen de datos:

    Cuentas tfsConfig /add /AccountType:ReportingDataSource /account:AccountName/SQLInstance:ServerName/DatabaseName:DatabaseName

    Para obtener más información, vea Accounts Command.

Actualizar los servidores de compilación

Ahora deberá redirigir los servidores de compilación para que apunten a la implementación de Azure DevOps Server movida.

  1. En cada servidor de compilación, abra la consola de administración y detenga el servicio de compilación.

  2. En las propiedades del servicio de compilación, actualice las propiedades de las comunicaciones.

    Detener el servicio y realizar los cambios a continuación

Configurar Reporting y Analysis Services

Si la implementación usa un servidor de informes, debe redirigir Azure DevOps Server a su ubicación, reiniciar el almacenamiento y recompilar manualmente la base de datos para Analysis Services. Si no usa informes, omita este procedimiento.

  1. Vaya al nodo Informes. Los valores del servidor de informes que se muestran aquí son los antiguos, no los nuevos; por tanto, edítelos.

    Los informes siguen señalando al servidor anterior

  2. Cambie los valores de las tres pestañas para apuntar al nuevo servidor. Asegúrese de proporcionar la información correcta de la cuenta de origen de datos en la nueva implementación.

    Asegurarse de que la información de las 3 pestañas sea correcta

  3. Elija Iniciar trabajos para reiniciar los informes.

  4. Elija Iniciar recompilación para recompilar el almacén.

Comprobar permisos de usuarios, grupos y cuentas de servicio

Después de mover al nuevo hardware, asegúrese de que todos los usuarios, grupos y cuentas de servicio de su implementación estén configurados con los permisos que necesitan para funcionar correctamente en cada servidor. Algunos permisos, como permisos adicionales en SQL Server o en el equipo local, no se pueden migrar automáticamente. Por ejemplo, los administradores de Azure DevOps deben ser miembros del grupo administradores local en el servidor de nivel de aplicación para abrir la consola de administración, por lo que debe agregarlos manualmente a ese grupo.

  • Inicie sesión en el servidor y asegúrese de que los usuarios, grupos y cuentas de servicio están configurados con los permisos necesarios. Inspeccione manualmente y al azar la pertenencia a equipos y grupos de proyectos, y compruebe que tienen los permisos esperados.

  • Vaya a una colección de proyectos y asegúrese de que todos los proyectos de esa colección aparezcan según lo previsto y que los usuarios de esos proyectos puedan acceder adecuadamente a sus elementos de trabajo.

  • Abra el portal web y compruebe que los sitios de grupo y los equipos aparecen según lo previsto.

¿No está seguro de qué grupos y permisos corresponde esperar en cada caso? Para obtener más información, vea Agregar usuarios a proyectos, Establecer permisos de administrador para colecciones de proyectos, Establecer permisos de administrador para Azure DevOps Server y cuentas de servicio y dependencias en Azure DevOps Server.

Actualizar la memoria caché de datos en los equipos cliente

  • Inicie sesión en el servidor y use el servicio web ClientService para obligar a los clientes a actualizar la memoria caché para realizar el seguimiento de elementos de trabajo y para el control de versiones de Azure DevOps.

    http://ServerName:8080/tfs/WorkItemTracking/v3.0/ClientService.asmx

    Para más información, consulte Actualización de las memorias caché de datos en equipos cliente.

    Si desea actualizar toda la memoria caché de todos los usuarios la próxima vez que inicie sesión, use el comando witadmin rebuildcache .

    Nota

    Si restauró las bases de datos a un momento dado diferente, también tendrá que actualizar la memoria caché del control de versiones como se documenta en Actualizar las cachés de datos en los equipos cliente.

Notificar a los usuarios

Ahora que ha movido Azure DevOps Server, deberá indicar a los usuarios cómo conectarse a la implementación movida. En concreto, deberá proporcionarles la siguiente información:

  • Nombre del nuevo servidor y la dirección URL del portal web, para que puedan volver a conectarse a sus proyectos.

  • Los nombres de base de datos nuevos para los informes, si estos últimos forman parte de la implementación

  • Si son miembros de un proyecto que usa Git, instrucciones para actualizar cada clon que tienen localmente para cada repositorio de ese proyecto. En concreto, tendrán que ejecutar el comando siguiente para cada clon:

    git remote set-url <remote name> <new URL>

    Los usuarios pueden ver cuál es la dirección URL de cada clon examinando el proyecto desde la pestaña Explorador.

    Copia de la dirección URL donde se va a clonar un repositorio manualmente

Configuración de copias de seguridad

Aunque tenía copias de seguridad programadas para la implementación anterior, estas no se modificaron para hacer copia de seguridad de la implementación que movió. Será necesario configurarlas.

  • En la consola de administración, vaya al nodo Copias de seguridad programadas y vuelva a configurar las copias de seguridad programadas para realizar copias de seguridad de las bases de datos de Azure DevOps Server en el nuevo servidor. Para obtener más información, consulte Create una programación y un plan de copia de seguridad.

Preguntas y respuestas

P: Deseo cambiar dominios, no servidores físicos. ¿Puedo hacerlo?

R: Sí. Esto se denomina movimiento basado en entornos y los pasos se pueden encontrar aquí. No debe intentar combinar un movimiento basado en el entorno con un movimiento basado en hardware. Complete primero el movimiento de hardware y después cambie el entorno.

P: Me di cuenta de que quiero seguir usando mi antigua Azure DevOps Server después de pasar a nuevo hardware. ¿Puedo hacerlo?

Un: Sí, pero es muy importante que realice pasos adicionales inmediatamente. Lo ideal sería que hubiera completado estos pasos durante el cambio o la clonación, ya que es la mejor manera de evitar el riesgo de daños en una o ambas implementaciones. Si ambos servidores están activos, podría acabar con daños, especialmente si apuntan a los mismos recursos de informes.

Para corregir este problema:

  1. Ejecute el comando TFSConfig PrepareClone en el nuevo servidor.

  2. Ejecute el comando CHANGEServerID de TFSConfig en el nuevo servidor.

  3. Ejecute el comando RemapDBs tfSConfig en el nuevo servidor.

P: Tengo una implementación que se integra con Project Server. ¿Tengo que realizar algún paso adicional para que funcione con mi Azure DevOps Server movido?

Un: Sí, después de completar el traslado de hardware, deberá usar el comando TFSAdmin ProjectServer/RegisterPWA con las opciones /tfs, /force y /pwa para volver a registrar Azure DevOps Server con Project Server. Puede obtener más información sobre Azure DevOps Server integración con Project Server aquí.