Renommer un projet dans Azure DevOps

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Le changement de nom d’un projet dans Azure DevOps met à jour le nom du projet dans les chemins de contrôle de version, les éléments de travail, les requêtes et d’autres artefacts de projet. Vous pouvez renommer un projet unique plusieurs fois et utiliser d’anciens noms. Après le renommage, certaines actions peuvent être nécessaires à partir des membres de l’équipe.

Avertissement

GitHub Copilot : Lors du changement de nom d’un projet, Azure DevOps avertit tous les membres du projet par e-mail si le nombre d’utilisateurs est inférieur à 1 000. Pour les projets avec plus de 1 000 utilisateurs, seuls les Administration istrateurs de collecte de projets reçoivent ces notifications.

Fédération des identités de charge de travail : le changement de nom d’un projet interrompt les sujets de fédération des identités de charge de travail dans les connexions de service Azure Resource Manager.

Prérequis

• Vous devez être membre du groupe Project Administration istrators ou disposer de l’autorisation Renommer le projet d’équipe au niveau du projet sur Autoriser. Pour plus d’informations, consultez Modifier les autorisations au niveau du projet.

Renommer un projet

1. Connectez-vous à votre organisation (https://dev.azure.com/{Your_Organization}), puis ouvrez le projet que vous souhaitez renommer.

2. Sélectionnez Vue d’ensemble des paramètres>du projet, puis entrez un nouveau nom, puis sélectionnez Enregistrer.

   

3. Pour confirmer le renommage, entrez le nouveau nom du projet, case activée la zone en regard de « Je comprends les conséquences du changement de nom de ce projet », puis sélectionnez Enregistrer.

   

Résultats du renommage

Les résultats suivants se produisent après l’opération de renommage.

• Azure DevOps renomme le projet.

• Tous les membres du projet reçoivent une notification par e-mail du changement de nom, si moins de 1 000 membres.

• L’URL continue de fonctionner pour le nouveau nom de l’équipe et l’ancien nom de l’équipe. Cette fonctionnalité est destinée à éviter les liens cassants.

• Si le projet dans l’URL est un projet valide dans l’organisation, nous affichons l’ID d’élément de travail fourni. L’exemple suivant montre une organisation avec des projets nommés « Example1 » et « Example2 ».

  https://dev.azure.com/MyOrg/Example1/_workitems/edit/40/ - Affiche l’élément de travail 40 https://dev.azure.com/MyOrg/Example2/_workitems/edit/40/ - Affiche l’élément de travail 40 https://dev.azure.com/MyOrg/Potato/_workitems/edit/40/ - Affiche une erreur 404

• Les ID d’élément de travail sont uniques dans l’organisation et, par conséquent, les liens n’expirent pas.

• L’ancien nom du projet peut être utilisé à nouveau.

Actions utilisateur requises pour l’utilisation du projet renommé

Chaque utilisateur au sein de votre équipe doit redémarrer ses clients et effectuer certaines des actions suivantes, en fonction des fonctionnalités qu’ils utilisent :

• Mettre à jour les distances Git
• Mettre à jour les espaces de travail serveur TFVC (Team Foundation Version Control)
• Mettre à jour les espaces de travail locaux TFVC

Redémarrer les clients

Les clients ouverts conservent un cache de tous les noms de projet en mémoire, mais ce cache n’est pas automatiquement effacé une fois qu’un projet est renommé. Pour effacer le cache, redémarrez votre client afin qu’il remplisse le nouveau nom du projet. Si vous ne redémarrez pas le client, les opérations qui utilisent le nom du projet mis en cache échouent avec une exception de projet introuvable .

Pour les clients suivants, enregistrez votre travail dans chacun d’eux, puis redémarrez :

• Visual Studio Team Explorer
• Microsoft Excel, si votre équipe utilise Azure DevOps Bureau Integration 2019

Mettre à jour les distances Git

Si votre projet utilise Git, vos références distantes pour chaque référentiel du projet renommé doivent être mises à jour. Ces mises à jour sont nécessaires, car l’URL dépôt distant contient le projet et le nom du référentiel. Git utilise des références distantes pour extraire et envoyer (push) les modifications entre votre référentiel local et la version distante stockée sur le serveur. Chaque membre de votre équipe doit mettre à jour ses dépôts Git locaux pour continuer à se connecter à partir de ses machines de développement.

Pour plus d’informations, consultez Mettre à jour les remotes Git sur vos machines de développement.

Mettre à jour les espaces de travail du serveur TFVC

Si votre projet utilise TFVC avec des espaces de travail serveur, ces espaces de travail doivent être mis à jour avec le nouveau nom du projet. Pour les clients Visual Studio, exécutez une opération get ou case activée, puis le mappage de l’espace de travail est corrigé pour utiliser le nouveau nom du projet.

Pour plus d’informations, consultez la commande Renommer (TFVC).

Mettre à jour les espaces de travail locaux TFVC

Si votre équipe utilise TFVC avec des espaces de travail locaux, ces espaces de travail doivent être mis à jour avec le nouveau nom du projet. Pour Visual Studio, exécutez une opération get ou case activée-in et le mappage de l’espace de travail est corrigé pour utiliser le nouveau nom du projet.

Nous vous recommandons de mettre à jour vos clients vers la dernière mise à jour ou la version, si possible. Pour toutes les autres versions de Visual Studio prises en charge, vous devez créer un espace de travail local mappé au nouveau nom du projet.

Les espaces de travail locaux sont gérés localement et non sur le serveur. Les clients plus anciens sans la logique de renommage mise à jour ne peuvent pas mettre à jour les espaces de travail locaux vers le nouveau nom du projet.

Articles connexes

• Supprimer un projet
• Git et Azure Repos

Forum Aux Questions (FAQ)

Q : Pourquoi ma tentative de réutilisation d’un nom de projet a-t-elle échoué en raison d’espaces de travail existants ?

R : Vous ne pouvez pas réutiliser un nom de projet s’il existe toujours des mappages d’espace de travail qui s’y adressent. Cette fonction permet d’éviter le cas d’ambiguïté dans lequel un espace de travail peut être mappé à deux projets. Contactez les utilisateurs qui ont ces mappages, puis supprimez-les ou mettez-les à jour pour utiliser le nouveau nom.

Si l’ordinateur de l’utilisateur contenant l’espace de travail n’est plus disponible, vous pouvez supprimer l’espace de travail en exécutant la commande suivante à partir de l’invite de commandes du développeur de Visual Studio : tf workspace /delete [/collection:TeamProjectCollectionUrl] workspacename[;workspaceowner]

Q : Comment le changement de nom d’un projet affecte-t-il l’expérience de navigation de mon navigateur ?

R : Après avoir renommé un projet, tous les navigateurs avec le projet ouvert peuvent rencontrer des erreurs. Ces erreurs sont dues aux caches conservés par le navigateur, qui incluent l’ancien nom du projet. Actualisez pour faire disparaître ces erreurs, car le cache est rerempli avec le nouveau nom du projet.

Q : Les autres artefacts du projet sont-ils renommés ?

R : Oui, tous les artefacts qui partagent le même nom sont renommés avec le projet. Les seules exceptions concernent l’équipe et le dépôt par défaut. Le renommage de ces artefacts est effectué comme un meilleur effort. Par exemple, si un projet Foo a été renommé bar, l’équipe par défaut Foo ne sera pas renommée si une équipe nommée Bar existait déjà dans le projet.

Q : Pourquoi ne puis-je pas ouvrir les requêtes enregistrées sur un disque après un renommage ?

R : Si vous utilisez Visual Studio 2010 et que vous avez des requêtes enregistrées sur le disque, vous ne pouvez pas les ouvrir après avoir renommé un projet. Vous pouvez utiliser Visual Studio 2012 ou une version ultérieure pour les ouvrir.