Compartir a través de

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 del software de Azure DevOps Server. Para mover Azure DevOps Server de una máquina a otra, restaure a nuevo hardware (denominado movimiento basado en restauración). Por ejemplo, puede que quiera 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 dejar de usar el hardware original y la implementación de Azure DevOps Server. Realice un clon cuando quiera seguir usando la instancia original de Azure DevOps Server.

Importante

En algunas situaciones, es posible que desee cambiar el dominio de una implementación de Azure DevOps Server, así como su hardware. Cambiar el dominio es un movimiento basado en entornos y nunca debe combinar los dos tipos de movimiento. En primer lugar, complete el movimiento de hardware y, a continuación, 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 interopera la implementación, como Project Server.

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

  • Servidores: administradores (grupo de administradores locales 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 de Azure DevOps Server y, en la página Copias de seguridad programadas , realice una copia de seguridad completa. La copia de seguridad hará una copia de seguridad de todo lo que configuró para la copia de seguridad 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 una copia de seguridad de la clave de cifrado como parte de este conjunto de copia 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 la copia de seguridad está disponible en el dispositivo de almacenamiento o en el recurso compartido de red, y que puede acceder a esta copia de seguridad desde el nuevo hardware.

Instalación y configuración de 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 usó informes, asegúrese de incluir los componentes de Reporting y Analysis Services. Debe instalar la misma versión y edición que usó anteriormente, incluidos los niveles de actualización acumulativa y Service Pack.

    Instalación de 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

Instalación y configuración de software en el nuevo servidor de nivel 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 siguientes componentes:

  • un sistema operativo compatible para la 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 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 de restauración en el nodo Copias de seguridad programadas.

Si desea restaurar las bases de datos de Azure DevOps Server manualmente mediante las herramientas de restauración de SQL Server, puede, pero es un procedimiento más difícil. Además, tendrá que anular manualmente la solicitud de las bases de datos en la nueva implementación. El asistente para la restauración 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érralo.

    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 de Azure DevOps Server y abra Copias de seguridad programadas.

    Iniciar el Asistente para restaurar

  4. Especifique la ruta de acceso al conjunto de copia de seguridad y elija el conjunto que creó después de poner en modo inactivo la implementación anterior.

    Elija la ruta de acceso de red y, a continuación, el conjunto de restauración.

  5. Complete 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 Clonar) Volver a configurar los identificadores de servidor y las bases de datos de reasignación

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 que ya estaba en producción en otro servidor. Este comando ya no es necesario, ya que hemos incorporado 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 original de Azure DevOps Server. Estos pasos son necesarios para evitar el riesgo de daños de 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 Drive:%programfiles%\TFS 12.0\Tools. Abra una ventana del 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 la implementación de Azure DevOps Server.

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

  4. Ejecute el comando RemapDBs de TFSConfig para redirigir el servidor de Azure DevOps 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 de nivel de aplicación y, en Bases de datos, especifique la nueva instancia de SQL Server donde restauró las bases de datos de Azure DevOps Server. Elija la base de datos Tfs_Configuration de la lista.

    Seleccione el conjunto de copia de seguridad de base de datos y SQL Server.

  3. Antes de cerrar la página final del asistente, busque el símbolo "i". Significa información que puede querer para referencia futura. La página final también incluye la ubicación del registro de configuración.

    Tenga en cuenta los problemas y la ubicación del archivo de registro

Actualización de las direcciones URL de Azure DevOps Server

  1. Vaya al nodo de nivel de aplicación y examine la notificación y las direcciones URL del portal web. Tenga en cuenta que siguen apuntando a la ubicación de la implementación anterior. Actualícelos.

    La notificación y las direcciones URL web no están actualizadas

  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 del servidor sigue usando localhost

Actualización de todas las cuentas de servicio

Debe actualizar la cuenta de servicio de 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 asegurarse de que la identidad y el formato de las cuentas son adecuados para el nuevo servidor.

  1. Abra una ventana del símbolo del sistema como administrador y cambie los directorios a Drive:\%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 orígenes de datos:

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

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

Actualizar 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 comunicaciones.

    Detenga el servicio y, a continuación, realice cambios.

Configuración de Reporting and Analysis Services

Si la implementación usa un servidor de informes, debe redirigir Azure DevOps Server a su ubicación, reiniciar el almacenamiento y volver a generar 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 enumerados son los antiguos, no los nuevos, por lo que los edita.

    Los informes siguen apuntando al servidor antiguo

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

    Asegúrese de que la información es correcta en las tres pestañas

  3. Elija Iniciar trabajos para reiniciar los informes.

  4. Elija Iniciar recompilación para recompilar el almacenamiento.

Comprobación de permisos para usuarios, grupos y cuentas de servicio

Después de pasar al nuevo hardware, asegúrese de que todos los usuarios, grupos y cuentas de servicio de la 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 para la operación. Compruebe manualmente la pertenencia a grupos de proyectos y equipos y compruebe que esos grupos y equipos tienen los permisos esperados.

  • Vaya a una colección de proyectos y asegúrese de que todos los proyectos de esa colección aparecen según lo previsto y que los usuarios de esos proyectos pueden 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 se esperan? Para más información, consulte Incorporación de usuarios a proyectos, Establecimiento de permisos de administrador para colecciones de proyectos, Establecimiento de permisos de administrador para Azure DevOps Server y cuentas de servicio y dependencias en Azure DevOps Server.

Actualización de la caché de datos en equipos cliente

  • Inicie sesión en el servidor y use el servicio web ClientService para obligar a los clientes a actualizar la 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 obtener más información, consulte Actualización de las memorias caché de datos en equipos cliente.

    Si desea actualizar toda la memoria caché para 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 memorias caché 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 nuevos nombres de base de datos para los informes, si los informes forman parte de la implementación

  • Si son miembros de un proyecto que usa Git, instrucciones sobre cómo actualizar cada clon que tienen localmente para cada repositorio de ese proyecto. En concreto, tendrán que ejecutar el siguiente comando 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 para clonar manualmente un repositorio en

Configuración de copias de seguridad

Aunque tenía copias de seguridad programadas para la implementación anterior, esas copias de seguridad programadas no se cambiaron para realizar copias de seguridad de la implementación movida. Deberá configurarlos.

  • 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 Creación de una programación y un plan de copia de seguridad.

Preguntas y respuestas

P: Quiero 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 entornos con un movimiento basado en hardware. En primer lugar, complete el movimiento de hardware y, a continuación, cambie el entorno.

P: Acabo de darse cuenta de que quiero seguir usando mi antiguo servidor de Azure DevOps después de pasar al nuevo hardware. ¿Puedo hacerlo?

R: Sí, pero es muy importante que realice pasos adicionales inmediatamente. Lo ideal es que haya realizado estos pasos como parte del movimiento o los pasos de clonación. Esa es la mejor manera de evitar el riesgo de daños de 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 PrepareClone de TFSConfig 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 pasos adicionales para que funcionen con mi servidor de Azure DevOps movido?

R: 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 la integración de Azure DevOps Server con Project Server aquí.