Déplacer ou cloner d’un matériel vers un autre pour Azure DevOps local

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

Vous pouvez déplacer ou cloner votre déploiement de logiciels Azure DevOps Server. Vous déplacez Azure DevOps Server d’un ordinateur vers un autre en le restaurant vers un nouveau matériel (appelé déplacement basé sur la restauration). Par exemple, vous souhaiterez peut-être déplacer Azure DevOps Server vers un serveur avec une capacité supérieure ou une vitesse de traitement améliorée. Lorsque vous passez à un nouveau serveur, vous ne perdez pas l’historique de votre projet.

Pour cloner votre déploiement Azure DevOps Server, vous effectuez les mêmes étapes qu’un déplacement et quelques autres.

Vous effectuez un déplacement lorsque vous envisagez d’interrompre l’utilisation du matériel d’origine et du déploiement d’Azure DevOps Server. Vous effectuez un clone lorsque vous envisagez de continuer à utiliser l’instance Azure DevOps Server d’origine.

Vérifier vos autorisations

Pour réussir à déplacer Azure DevOps Server, vous devez être administrateur sur les deux ensembles de matériels (l’ancien et le nouveau). En outre, vous devez être administrateur (ou disposer des autorisations équivalentes) pour Azure DevOps Server et tous les logiciels dont dépend votre déploiement : SQL Server, reporting et tout autre logiciel avec lequel votre déploiement interopére, tel que Project Server.

Vérifiez que vous êtes membre des groupes suivants :

• Serveurs : Administrateurs (groupe Administrateurs locaux ou équivalent)
• Azure DevOps Server : Administrateurs Team Foundation et utilisateurs de la console d’administration
• SQL Server : sysadmin

Si vous n’êtes pas membre d’un ou plusieurs de ces groupes, obtenez des autorisations maintenant.

Sauvegarder des bases de données et une clé de chiffrement

1. Ouvrez la console d’administration pour Azure DevOps Server et, dans la page Sauvegardes planifiées , effectuez une sauvegarde complète. La sauvegarde sauvegarde tout ce que vous avez configuré pour la sauvegarde dans votre plan de sauvegarde, mais elle le fera immédiatement, pas selon le temps planifié dans le plan. Si votre déploiement utilise la création de rapports, vous pouvez sauvegarder la clé de chiffrement dans le cadre de ce jeu de sauvegarde.

   

   (Si vous ne disposez pas de sauvegardes configurées, vous devez créer un plan avant de pouvoir effectuer une sauvegarde complète.)

2. Une fois la sauvegarde terminée, vérifiez que la sauvegarde est disponible sur le périphérique de stockage ou le partage réseau, et que vous pouvez accéder à cette sauvegarde à partir du nouveau matériel.

Installer et configurer SQL Server sur le nouveau serveur de couche Données

• Installez SQL Server sur le nouveau serveur et assurez-vous qu’il est opérationnel. Si votre déploiement précédent a utilisé la création de rapports, assurez-vous d’inclure les composants reporting et analysis Services. Vous devez installer la même version et l’édition que vous avez utilisées précédemment, y compris les niveaux de mise à jour cumulés et service Pack.

  

  En guise d’alternative, vous pouvez créer une instance de SQL Server sur un serveur qui dispose déjà d’une version correspondante installée et restaurer les bases de données Azure DevOps Server sur cette instance, mais qui nécessite plus de configuration après restauration.

  Pour plus d’informations sur les options d’installation et de configuration de SQL Server, accédez ici.

  Après avoir installé SQL Server, si votre déploiement inclut la création de rapports, ouvrez SQL Server Management Studio et détachez les bases de données ReportServer et ReportServerTempDB. Sinon, vous ne pourrez peut-être pas restaurer ces bases de données avec la sauvegarde que vous avez créée pour les bases de données Azure DevOps Server.

  

Installer et configurer des logiciels sur le nouveau serveur de la couche Application

Pour configurer un nouveau serveur ou serveur pour Azure DevOps Server, vous devez d’abord installer et configurer le logiciel requis pour le prendre en charge. Ce logiciel inclut les composants suivants :

• un système d’exploitation pris en charge pour votre configuration de déploiement

• Installez et configurez Windows, IIS (s’il n’est pas configuré par défaut) et assurez-vous que le serveur et son logiciel sont opérationnels. 

  Pour plus d’informations, consultez la configuration système requise pour Azure DevOps Server.

Restaurer les bases de données Azure DevOps Server

Pour restaurer les bases de données Azure DevOps Server à l’aide de l’outil de restauration, vous devez installer, mais pas configurer Azure DevOps Server sur le nouveau serveur de couche données, puis utiliser la fonction de restauration dans le nœud Sauvegardes planifiées.

Si vous souhaitez restaurer manuellement des bases de données Azure DevOps Server à l’aide d’outils de restauration SQL Server, vous pouvez, mais c’est une procédure plus difficile. En outre, vous devrez annuler manuellement les bases de données dans le nouveau déploiement. L’Assistant restauration dans Azure DevOps Server effectue automatiquement cette opération pour vous dans le cadre de son processus de restauration, mais cette fonctionnalité ne fait pas partie des outils de restauration de SQL Server.

1. Lancez le support d’installation d’Azure DevOps Server. Dans la page d’installation de Team Foundation Server, choisissez Installer.

2. Une fois l’installation terminée, le Centre de configuration Team Foundation Server s’ouvre. Fermez-le.

   La console d’administration s’ouvre automatiquement dans un état non configuré. Ceci est normal.

3. Pour démarrer l’Assistant Restauration, ouvrez la console d’administration pour Azure DevOps Server et ouvrez sauvegardes planifiées.

   

4. Spécifiez le chemin d’accès au jeu de sauvegarde et choisissez le jeu que vous avez créé après avoir arrêté l’ancien déploiement.

   

5. Terminez l’Assistant et restaurez les bases de données sur la nouvelle instance de SQL Server.

   

(Option Clone) Reconfigurer les ID de serveur et les bases de données de remappage

Effectuez l’ensemble suivant d’étapes sur le nouveau serveur de la couche Application si vous envisagez de continuer à utiliser l’instance azure DevOps Server d’origine. Ces étapes sont nécessaires pour éviter le risque d’altération d’un ou des deux déploiements. Si les deux serveurs sont en direct, vous risquez d’être endommagé, en particulier s’ils pointent vers les mêmes ressources de création de rapports.

1. Ouvrez une fenêtre d’invite de commandes en tant qu’administrateur et modifiez les répertoires en Drive :%programfiles%\TFS 12.0\Tools. Ouvrez une fenêtre d’invite de commandes et entrez :

2. Exécutez la commande TFSConfig PrepareClone pour supprimer des informations sur les sauvegardes planifiées et les ressources de création de rapports.

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

3. Exécutez la commande TFSConfig ChangeServerID pour modifier les GUID du serveur associés aux bases de données. Les GUID doivent être uniques dans le déploiement d’Azure DevOps Server.

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

4. Exécutez la commande TFSConfig RemapDBs pour rediriger le serveur Azure DevOps cloné vers ses bases de données.

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

Configurer le serveur de la couche Application

1. Dans la console d’administration d’Azure DevOps Server, choisissez Configurer les fonctionnalités installées pour lancer le centre de configuration.

2. Lancez l’Assistant Application-Tier Uniquement et, dans Bases de données, spécifiez la nouvelle instance SQL Server où vous avez restauré les bases de données Azure DevOps Server. Choisissez la base de données Tfs_Configuration dans la liste.

   

3. Avant de fermer la page finale de l’Assistant, recherchez le symbole « i ». Cela signifie que vous souhaiterez peut-être obtenir des informations de référence ultérieures. La page finale inclut également l’emplacement du journal de configuration.

   

Mettre à jour les URL du serveur Azure DevOps

1. Accédez au nœud de la couche Application et examinez la notification et les URL du portail web. Notez qu’ils pointent toujours vers l’emplacement de l’ancien déploiement. Mettez-les à jour.

   

2. Après avoir mis à jour les URL avec le nom du nouveau serveur, passez en revue les informations pour vous assurer qu’elles sont correctes.

   

Mettre à jour tous les comptes de service

Vous devez mettre à jour le compte de service pour Azure DevOps Server (TFSService) et le compte de sources de données (TFSReports). Même si ces comptes n’ont pas changé, vous devez mettre à jour les informations pour vous assurer que l’identité et le format des comptes sont appropriés pour le nouveau serveur.

1. Ouvrez une fenêtre d’invite de commandes en tant qu’administrateur et modifiez les répertoires en Drive :\%programfiles%\TFS 12.0\Tools.

2. À l’invite de commandes, tapez la commande suivante pour ajouter le compte de service pour Azure DevOps, où DatabaseName est le nom de la base de données de configuration (par défaut, TFS_Configuration) :

   Comptes TfsConfig /add /AccountType :ApplicationTier /account : AccountName /SQLInstance : ServerName /DatabaseName : DatabaseName

3. À l’invite de commandes, tapez la commande suivante pour ajouter le compte de sources de données :

   Comptes TfsConfig /add /AccountType :ReportingDataSource /account : AccountName /SQLInstance :ServerName /DatabaseName :DatabaseName

   Pour plus d’informations, consultez Commande Comptes.

Mettre à jour les serveurs de build

Vous devez maintenant rediriger vos serveurs de build pour pointer vers le déploiement d’Azure DevOps Server déplacé.

1. Sur chaque serveur de build, ouvrez la console d’administration et arrêtez le service de build.

2. Dans les propriétés du service de build, mettez à jour les propriétés de communication.

   

Configurer Reporting et Analysis Services

Si votre déploiement utilise un serveur de rapports, vous devez rediriger Azure DevOps Server vers son emplacement, redémarrer l’entrepôt et reconstruire manuellement la base de données pour Analysis Services. Si vous n’utilisez pas la création de rapports, ignorez cette procédure.

1. Accédez au nœud Reporting. Les valeurs du serveur de rapports répertoriées sont les anciennes, et non les nouvelles, de sorte à les modifier.

   

2. Modifiez les valeurs des trois onglets pour pointer vers le nouveau serveur. Veillez à fournir les informations appropriées pour le compte de sources de données dans le nouveau déploiement.

   

3. Choisissez Démarrer les travaux pour redémarrer la création de rapports.

4. Choisissez Démarrer la reconstruction pour reconstruire l’entrepôt.

Vérifier les autorisations pour les utilisateurs, les groupes et les comptes de service

Après avoir passé au nouveau matériel, assurez-vous que tous les utilisateurs, groupes et comptes de service pour votre déploiement sont configurés avec les autorisations dont ils ont besoin pour fonctionner correctement sur chaque serveur. Certaines autorisations, telles que des autorisations supplémentaires dans SQL Server ou sur l’ordinateur local, ne peuvent pas être migrées automatiquement. Par exemple, les administrateurs Azure DevOps doivent être membres du groupe Administrateurs local sur le serveur de la couche Application pour ouvrir la console d’administration. Vous devez donc les ajouter manuellement à ce groupe.

• Connectez-vous au serveur et assurez-vous que les utilisateurs, les groupes et les comptes de service sont configurés avec les autorisations requises pour l’opération. Vérifiez manuellement l’appartenance aux groupes de projets et aux équipes, puis vérifiez que ces groupes et équipes disposent des autorisations attendues.

• Accédez à une collection de projets et assurez-vous que tous les projets de cette collection apparaissent comme prévu, et que les utilisateurs de ces projets peuvent accéder correctement à leurs éléments de travail.

• Ouvrez le portail web et vérifiez que les sites d’équipe et les équipes apparaissent comme prévu.

Vous ne savez pas quels groupes et autorisations attendent-ils ? Pour plus d’informations, consultez Ajouter des utilisateurs à des projets, définir des autorisations d’administrateur pour les collections de projets, définir des autorisations d’administrateur pour Azure DevOps Server et des comptes de service et des dépendances dans Azure DevOps Server.

Actualiser le cache de données sur les ordinateurs clients

• Connectez-vous au serveur et utilisez le service web ClientService pour forcer les clients à mettre à jour le cache pour le suivi des éléments de travail et pour le contrôle de version Azure DevOps.

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

  Pour plus d’informations, consultez Actualiser les caches de données sur les ordinateurs clients.

  Si vous souhaitez actualiser l’intégralité du cache pour tous les utilisateurs la prochaine fois qu’ils se connectent, utilisez la commande witadmin rebuildcache .

  Remarque

  Si vous avez restauré vos bases de données à un autre point dans le temps, vous devez également actualiser le cache de contrôle de version comme documenté dans Actualiser les caches de données sur les ordinateurs clients.

Notifier les utilisateurs

Maintenant que vous avez déplacé Azure DevOps Server, vous devez indiquer à vos utilisateurs comment se connecter au déploiement déplacé. Plus précisément, vous devez leur fournir les informations suivantes :

• Nom du nouveau serveur et de l’URL du portail web, afin qu’ils puissent se reconnecter à leurs projets

• Les nouveaux noms de base de données pour la création de rapports, si la création de rapports fait partie de votre déploiement

• S’ils sont membres d’un projet qui utilise Git, des instructions pour mettre à jour chaque clone qu’ils ont localement pour chaque dépôt pour ce projet. Plus précisément, ils devront exécuter la commande suivante pour chaque clone :

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

  Les utilisateurs peuvent voir l’URL de chaque clone en parcourant le projet à partir de l’onglet Explorateur.

  

Configurer des sauvegardes

Bien que vous ayez planifié des sauvegardes pour votre ancien déploiement, ces sauvegardes planifiées n’ont pas été modifiées pour sauvegarder votre déploiement déplacé. Vous devez les configurer.

• Dans la console d’administration, accédez au nœud Sauvegardes planifiées et reconfigurez les sauvegardes planifiées pour sauvegarder les bases de données Azure DevOps Server sur le nouveau serveur. Pour plus d’informations, consultez Créer une planification et un plan de sauvegarde.

Questions & réponses

Q : Je souhaite modifier des domaines, et non des serveurs physiques. Est-ce possible ?

R : Oui. C’est ce qu’on appelle un déplacement basé sur l’environnement, et les étapes sont disponibles ici. Vous ne devez pas essayer de combiner un déplacement basé sur l’environnement avec un déplacement basé sur le matériel. Commencez par terminer le déplacement matériel, puis modifiez l’environnement.

Q : Je viens de réaliser que je veux continuer à utiliser mon ancien serveur Azure DevOps après le passage à un nouveau matériel. Est-ce possible ?

R : Oui, mais il est très important que vous effectuez immédiatement des étapes supplémentaires. Dans l’idéal, vous devez avoir effectué ces étapes dans le cadre du déplacement ou des étapes de clonage. C’est la meilleure façon d’éviter le risque de corruption d’un ou des deux déploiements. Si les deux serveurs sont en direct, vous risquez d’être endommagé, en particulier s’ils pointent vers les mêmes ressources de création de rapports.

Pour corriger ce problème :

1. Exécutez la commande TFSConfig PrepareClone sur le nouveau serveur

2. Exécutez la commande TFSConfig ChangeServerID sur le nouveau serveur

3. Exécutez la commande TFSConfig RemapDBs sur le nouveau serveur

Q : J’ai un déploiement qui s’intègre à Project Server. Dois-je effectuer des étapes supplémentaires pour qu’elle fonctionne avec mon serveur Azure DevOps déplacé ?

R : Oui, une fois le déplacement matériel terminé, vous devez utiliser la commande TFSAdmin ProjectServer /RegisterPWA avec les options /tfs, /force et /pwa pour réinscrire Azure DevOps Server auprès de Project Server. Vous pouvez en savoir plus sur l’intégration d’Azure DevOps Server à Project Server ici.