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

Article
04/03/2024

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

Vous pouvez déplacer ou cloner votre déploiement de Azure DevOps Server logiciel. Vous déplacez Azure DevOps Server d’un ordinateur à l’autre en le restaurant sur un nouveau matériel (appelé déplacement basé sur la restauration). Par exemple, vous pouvez 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 aucun de votre historique de projet.

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

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

Important

Dans certains cas, vous pouvez modifier le domaine d’un déploiement Azure DevOps Server ainsi que son matériel. Changer le domaine est un déplacement basé sur l'environnement, et vous ne devez jamais combiner les deux types de déplacement. Procédez d'abord au déplacement du matériel, puis modifiez l'environnement.

Vérifier vos autorisations

Pour réussir le déplacement de Azure DevOps Server, vous devez être administrateur sur les deux ensembles de matériel (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, création de rapports et tout autre logiciel avec lequel votre déploiement interagit, comme Project Server.

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

Serveurs : administrateurs (groupe Administrateurs local ou équivalent)
Azure DevOps Server : Administrateurs Team Foundation et utilisateurs de la console Administration
SQL Server : sysadmin

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

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

Ouvrez la console d’administration pour Azure DevOps Server et, dans la page Sauvegardes planifiées, effectuez une sauvegarde complète. La sauvegarde enregistrera tous les éléments que vous avez configurés pour la sauvegarde dans votre plan de sauvegarde, mais cette opération sera effectuée immédiatement, et pas en fonction du délai 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 cet ensemble de sauvegardes.

(Si vous n’avez pas configuré de sauvegardes, vous devez créer un plan avant de pouvoir effectuer une sauvegarde complète.)
Une fois la sauvegarde terminée, vérifiez qu'elle est disponible sur le dispositif de stockage ou le partage réseau et que vous pouvez y accéder à 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 utilise la création de rapports, veillez à inclure les composants Reporting Services et Analysis Services. Vous devez installer la même version et la même édition que celles que vous avez utilisées précédemment, notamment le Service Pack et les niveaux des mises à jour cumulatives.

Vous pouvez également créer une instance de SQL Server sur un serveur sur lequel une version correspondante est déjà installée et restaurer les bases de données Azure DevOps Server dans cette instance, mais cela nécessite une configuration post-restauration plus grande.

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

Après l'installation de 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 risquez de ne pas pouvoir 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 les logiciels sur le nouveau serveur de couche Application

Pour configurer un ou plusieurs serveurs pour Azure DevOps Server, vous devez d’abord installer et configurer le logiciel requis pour le prendre en charge. Ces logiciels incluent 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 ses logiciels 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 la couche Données, puis utiliser la fonction de restauration dans le nœud Sauvegardes planifiées.

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

Lancez le support d’installation Azure DevOps Server. Dans la page Installation de Team Foundation Server , choisissez Installer.
Une fois l’installation terminée, le Centre de configuration Team Foundation Server s’ouvre . Fermez-le.

La console Administration s'ouvre automatiquement dans un état non configuré. Ceci est normal.
Pour démarrer l’Assistant Restauration, ouvrez la console d’administration pour Azure DevOps Server et ouvrez Sauvegardes planifiées.
Spécifiez le chemin d'accès au jeu de sauvegardes et choisissez le jeu que vous avez créé après avoir suspendu l'ancien déploiement.
Suivez la procédure de l'Assistant et restaurez les bases de données sur la nouvelle instance de SQL Server.

(Option de clonage) Reconfigurer les ID de serveur et remapper les bases de données

Notes

L’utilisation de PrepareClone était recommandée avant de mettre en place un nouveau déploiement Azure DevOps Server à l’aide d’une sauvegarde de base de données déjà en production sur un autre serveur. Cette commande n’est plus nécessaire, car nous avons incorporé ses fonctionnalités dans les scénarios de mise à niveau et de clonage de préproduction dans l’Assistant Configuration.

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

Ouvrez une fenêtre d’invite de commandes en tant qu’administrateur et remplacez les répertoires par Drive :%programfiles%\TFS 12.0\Tools. Ouvrez une fenêtre d'invite de commandes et entrez la commande suivante :
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
```
Exécutez la commande TFSConfig ChangeServerID pour modifier les GUID de serveur associés aux bases de données. Les GUID doivent être uniques dans Azure DevOps Server déploiement.
```
TFSConfig ChangeServerID /SQLInstance:ServerName] /DatabaseName:ConfigurationDatabaseName [/ProjectCollectionsOnly] [/ConfigDBOnly] [/usesqlalwayson]
```

Exécutez la commande TFSConfig RemapDBs pour rediriger le Azure DevOps Server 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

Dans la console d’administration de Azure DevOps Server, choisissez Configurer les fonctionnalités installées pour lancer le centre de configuration.
Lancez l’Assistant Application-Tier uniquement et, dans Bases de données, spécifiez la nouvelle SQL Server instance où vous avez restauré les bases de données Azure DevOps Server. Sélectionnez la base de données Tfs_Configuration dans la liste.
Avant de fermer la dernière page de l'Assistant, recherchez le symbole « i ». Il désigne des informations utiles pour une référence ultérieure. La dernière page comprend également l'emplacement du journal de configuration.

Mettre à jour les URL Azure DevOps Server

Accédez au nœud de niveau application et examinez la notification et les URL du portail web. Notez qu'elles pointent toujours vers l'emplacement de l'ancien déploiement. Mettez-les à jour.
Après la mise à jour des URL avec le nom du nouveau serveur, examinez 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 contribuer à garantir que l'identité et le format des comptes sont appropriés pour le nouveau serveur.

Ouvrez une fenêtre d’invite de commandes en tant qu’administrateur et remplacez les répertoires par Drive :\%programfiles%\TFS 12.0\Tools.
À 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
À 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 qu’ils pointent vers le déploiement Azure DevOps Server déplacé.

Sur chaque serveur de build, ouvrez la console Administration et arrêtez le service de build.
Dans les propriétés du service de build, mettez à jour les propriétés de communication.

Configurer les services Reporting Services 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 les rapports, ignorez cette procédure.

Accédez au nœud Rapports. Les valeurs du serveur de rapports répertoriées sont les anciennes, et non les nouvelles. Il faut donc les modifier.
Modifiez les valeurs des trois onglets pour qu'elles pointent vers le nouveau serveur. Veillez à fournir les informations appropriées pour le compte de sources de données dans le nouveau déploiement.
Choisissez Démarrer les travaux pour redémarrer la création de rapports.
Choisissez Démarrer la reconstruction pour reconstruire l’entrepôt.

Vérifiez les autorisations relatives aux utilisateurs, aux groupes et aux comptes de service

Après avoir effectué un déplacement vers un nouveau matériel, vérifiez que tous les utilisateurs, groupes et comptes de service du déploiement sont configurés avec les autorisations appropriées pour un fonctionnement correct sur chaque serveur. Certaines autorisations, telles que les 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 vérifiez que les utilisateurs, groupes et comptes de service sont configurés avec les autorisations nécessaires. Contrôlez manuellement l'appartenance aux groupes et équipes de projet et vérifiez que ces groupes et équipes disposent des autorisations prévues.
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 de manière appropriée à 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 à quelles autorisations vous attendre ? 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 Comptes de service et 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 lors de leur prochaine connexion, utilisez la commande witadmin rebuildcache .

Notes

Si vous avez restauré vos bases de données à un autre moment dans le temps, vous devez également actualiser le cache de contrôle de version comme indiqué 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 spécifiquement, vous devez leur fournir les informations suivantes :

Nom du nouveau serveur et l’URL du portail web, afin qu’ils puissent se reconnecter à leurs projets
les nouveaux noms de bases de données pour l'enregistrement, si l'enregistrement fait partie de votre déploiement ;
S’ils sont membres d’un projet qui utilise Git, vous trouverez des instructions pour mettre à jour chaque clone dont ils disposent localement pour chaque dépôt pour ce projet. Plus spécifiquement, 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 Explorer.

Configurer des sauvegardes

Bien que vous ayez eu des sauvegardes planifiées 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 et réponses

Q : Je souhaite modifier les domaines, et non les 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. Procédez d'abord au déplacement du matériel, puis modifiez l'environnement.

Q : Je viens de réaliser que je veux continuer à utiliser mon ancien Azure DevOps Server après avoir passé au nouveau matériel. Est-ce possible ?

Un: Oui, mais il est très important d’effectuer des étapes supplémentaires immédiatement. Dans l'idéal, vous auriez dû effectuer ces étapes dans le cadre du déplacement ou de la procédure de clonage. Il s'agit de la méthode la mieux adaptée pour éviter le risque d'endommagement de l'un ou des deux déploiements. Si les deux serveurs sont en vie, 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 :

Exécutez la commande TFSConfig PrepareClone sur le nouveau serveur
Exécutez la commande TFSConfig ChangeServerID sur le nouveau serveur
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’il fonctionne avec mon Azure DevOps Server déplacé ?

Un: Oui, une fois le déplacement du 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 Azure DevOps Server’intégration à Project Server ici.