Vue d’ensemble de la migration

Le passage d’Azure DevOps Server à Azure DevOps Services est une étape essentielle pour les organisations qui souhaitent tirer parti de la collaboration, de l’extensibilité et des fonctionnalités améliorées basées sur le cloud. Dans cette vue d’ensemble, nous explorons les options permettant de transférer vos données précieuses à partir du serveur Azure DevOps local vers Azure DevOps Services basé sur le cloud.

Pour plus d’informations sur les principales différences entre azure DevOps Server local et Azure DevOps Services basé sur le cloud, consultez Comparer Azure DevOps Services à Azure DevOps Server - Azure DevOps Server.

Quelle que soit votre option de migration sélectionnée, nous vous recommandons de déterminer vos ressources les plus importantes, telles que le code source et les éléments de travail. Vous devez réfléchir à la taille de vos données, à la complexité de l’organisation et à vous assurer que vous avez suffisamment de temps pour les exécutions de test avant la migration réelle pour une transition fluide et réussie.

Approches de la migration

Il est essentiel d’évaluer les avantages et les inconvénients de chaque approche de la migration, en fonction de vos motivations spécifiques pour l’adoption d’Azure DevOps Services. La bonne stratégie dépend de votre contexte et de vos exigences uniques.

Option 1 : Migration manuelle

Par exemple, lorsque l’équipe Azure DevOps chez Microsoft a choisi de passer d’Azure DevOps Server à Azure DevOps Services, nous avons également décidé de passer de Team Foundation Version Control (TFVC) à Git. La migration nécessite un grand nombre de planifications, mais lorsque nous avons migré, nous avons créé un dépôt Git à l’aide de la version « tip » de nos sources TFVC et nous avons laissé notre historique dans Azure DevOps Server. Nous avons également déplacé nos éléments de travail actifs, et laissé derrière tous nos anciens bogues, terminé les récits utilisateur et les tâches, et ainsi de suite.

Processus de migration manuelle

1. Identifiez les ressources les plus importantes dont vous avez besoin pour migrer , généralement le code source, les éléments de travail ou les deux. D’autres ressources dans Azure DevOps Server - générer des pipelines, des plans de test, etc. sont plus difficiles à migrer manuellement.
2. Identifiez un moment approprié pour effectuer la transition.
3. Préparez vos organisations cibles. Créez les organisations et les projets d’équipe dont vous avez besoin, approvisionnez les utilisateurs, et ainsi de suite.
4. Migrez vos données.
5. Envisagez de rendre les déploiements Azure DevOps Server sources en lecture seule. Pour ce faire, procédez comme suit :
   • Ajustez les autorisations au niveau du projet : définissez les autorisations pour tous les utilisateurs ou groupes en lecture seule au niveau du projet, que vous pouvez faire en modifiant les rôles de sécurité dans les paramètres du projet.
   • Modifier les paramètres du référentiel : pour chaque référentiel, vous pouvez modifier les paramètres pour les rendre en lecture seule, ce qui implique d’ajuster les autorisations pour chaque utilisateur ou groupe afin d’autoriser uniquement les actions de lecture.
   • Utilisez des groupes de sécurité intégrés : utilisez les groupes de sécurité intégrés pour gérer les autorisations plus efficacement. Vous pouvez affecter des utilisateurs à des groupes tels que « Lecteurs » pour fournir un accès en lecture seule.
   • Modifications des autorisations de script : si vous avez de nombreux projets ou référentiels, vous devrez peut-être les scripter. Vous pouvez utiliser l’extension Azure CLI DevOps pour répertorier toutes les autorisations et les mettre à jour si nécessaire.
   • Désactiver la fonctionnalité de référentiel : désactive l’accès au référentiel, y compris les builds et les demandes de tirage( pull), mais conserve le référentiel détectable avec un avertissement. Accédez aux référentiels des> paramètres>du projet, puis, en regard de Désactiver le dépôt, déplacez le bouton bascule sur Activé.

Option 2 : Outil de migration de données Azure DevOps

L’outil de migration de données Azure DevOps est un ensemble d’utilitaires fournis par Microsoft pour faciliter la migration des données d’Azure DevOps Server vers Azure DevOps Services. Ces outils offrent une approche simplifiée pour migrer différents artefacts, notamment le code source, les éléments de travail, les cas de test et d’autres données liées au projet.

Avant de lancer le processus de migration, les outils peuvent effectuer une analyse de prémigration pour évaluer la préparation de l’environnement source et identifier les problèmes potentiels ou les dépendances susceptibles d’affecter la migration. Évaluez la préparation, de sorte que vous puissiez planifier et atténuer les défis potentiels au préalable.

Limitations de l’outil de migration

L’outil vous permet de « lever et déplacer » une collection de serveurs Azure DevOps vers une nouvelle organisation azure DevOps Service, sans aucune modification pour les raisons suivantes :

• Intégrité et cohérence des données :
  • Lorsque vous migrez des données, la maintenance de l’intégrité et de la cohérence est cruciale. L’autorisation de modifications pendant la migration peut entraîner une altération des données ou des incohérences.
  • L’outil garantit que les données restent intactes pendant le processus de transfert, ce qui réduit le risque d’erreurs.
• Conservation des données sources :
  • L’outil de migration vise à répliquer fidèlement les données sources dans l’environnement cible.
  • Les modifications peuvent modifier les données d’origine, ce qui peut entraîner des différences entre les données migrées et les données sources.
• Comportement prévisible :
  • En limitant les modifications, l’outil garantit un comportement prévisible pendant la migration.
  • Les utilisateurs peuvent s’appuyer sur des résultats cohérents sans modifications inattendues.
• Focus de migration, pas transformation :
  • L’objectif principal de l’outil de migration est de déplacer des données d’un emplacement à un autre.
  • La transformation des données (par exemple, la modification de valeurs) est généralement gérée séparément après la migration.

Vous pouvez vider les données dont vous n’avez pas besoin avant ou après la migration.

Processus de l’outil de migration

1. Remplissez les conditions préalables, telles que la mise à jour d’Azure DevOps Server vers l’une des deux versions les plus récentes.
2. Validez chaque collection que vous souhaitez déplacer vers Azure DevOps Services.
3. Générez des fichiers de migration.
4. Préparez tout pour l’exécution de votre migration.
5. Effectuez une exécution de test.
6. Effectuer une migration.
7. Vérifiez que vos utilisateurs et vos données ont été migrés et que la collection fonctionne comme prévu.

Option 3 : Migration basée sur l’API

Si, pour une raison quelconque, vous ne pouvez pas utiliser l’outil de migration de données, mais que vous souhaitez toujours une migration de fidélité supérieure à l’option 2, vous pouvez choisir parmi différents outils qui utilisent des API publiques pour déplacer des données.

Limitations de migration basées sur l’API

Les limitations suivantes se produisent avec la migration basée sur l’API :

• Migration à faible fidélité :
  • Limitation : les outils basés sur l’API offrent une fidélité plus élevée que la copie manuelle, mais restent relativement faibles.
  • Implication : Bien que ces outils offrent une certaine fidélité, ils ne conservent pas tous les aspects de vos données.
    • Exemple : aucun d’entre eux ne conserve les dates d’origine des ensembles de modifications TFVC (Team Foundation Version Control).
    • Beaucoup ne conservent pas non plus les dates modifiées des révisions d’éléments de travail.
• Modification de la perte de données et de l’ID :
  • Limitation : pendant la migration, les outils relectent les modifications des éléments de travail, les ensembles de modifications TFVC, les flux de package et les artefacts de pipeline.
  • Implication : ce processus peut entraîner une perte de données, générer de nouveaux ID et modifier la création, la modification et les dates de fermeture.
    • Exemple : le contexte historique lié à des dates spécifiques peut être perdu, ce qui affecte la création de rapports et la traçabilité.

Processus de migration basé sur l’API

En général, nous vous recommandons uniquement cette approche si une fidélité supplémentaire au-delà d’une copie manuelle est essentielle. Si vous décidez d’adopter cette approche, vous pouvez envisager d’embaucher un consultant qui a de l’expérience avec un ou plusieurs des outils et effectuer une migration de test avant votre migration finale.

De nombreuses organisations ont besoin d’une migration très haute fidélité uniquement pour un sous-ensemble de leur travail. Le nouveau travail peut potentiellement démarrer directement dans Azure DevOps Services. D’autres travaux, avec des exigences de fidélité moins strictes, peuvent être migrés à l’aide de l’une des autres approches.

Modèles de processus pris en charge

Azure DevOps Services prend en charge les modèles de processus suivants :

• Hérité
• XML hébergé

Par défaut, le code XML hébergé est désactivé dans Azure DevOps Services. Nous allons activer le modèle de processus XML hébergé pendant la migration uniquement si vous avez personnalisé un projet dans Azure DevOps Server. Une fois que votre projet est sur le code XML hébergé, vous pouvez le mettre à niveau vers une version héritée après la migration.

Principes clés

Lors de la migration vers Azure DevOps Services, gardez à l’esprit les principes et limitations clés suivants :

• Azure DevOps Services est en anglais uniquement : Azure DevOps Server prend en charge plusieurs langues, mais aujourd’hui, Azure DevOps Services prend uniquement en charge l’anglais. Si votre collection utilise la langue autre que l’anglais ou utilisé autre que l’anglais dans le passé et que vous avez converti la langue en anglais pendant une mise à niveau, vous ne pouvez pas utiliser l’outil de migration de données.
• Héritage : un projet créé à partir du modèle de processus Agile, Scrum ou CMMI et qui n’a jamais été personnalisé, se trouve sur le modèle de processus d’héritage après la migration.
• XML hébergé : tout projet avec personnalisations utilise le modèle de processus XML hébergé.
• Processus par projet personnalisé : bien qu’Azure DevOps Services autorise les projets à partager un processus, l’outil de migration de données crée un processus XML hébergé pour chaque projet d’équipe personnalisé. Par exemple, si vous avez 30 projets personnalisés, vous avez 30 processus XML hébergés à gérer. Si vous souhaitez personnaliser davantage votre processus XML hébergé pour tous vos projets, vous devez mettre à jour chaque processus XML hébergé séparément.
• Validation du processus : la validation du processus de l’outil de migration de données détecte le modèle de processus cible pour chaque projet. Avant de pouvoir migrer, vous devez corriger les erreurs de validation de processus pour les projets XML hébergés. Vous pouvez envisager de mettre à jour le processus de vos projets pour qu’ils correspondent à l’un de nos processus (Agile, Scrum ou CMMI) pour tirer parti du modèle de processus d’héritage. En savoir plus sur les types de validation de processus dans notre documentation.

Ressources

• Signaler un problème dans la communauté des développeurs
• Obtenir du support et fournir des commentaires

Étapes suivantes

Articles connexes

• Prérequis complets pour la migration
• Valider et préparer la migration
• Préparer l’exécution des tests
• Effectuer une migration d’exécution de test
• Migrer vers Azure DevOps Services
• Effectuer des tâches postérieures à la migration