Partager via

Migrer vers Git à partir du contrôle de version centralisé

La migration d’une équipe vers Git à partir du contrôle de version centralisé nécessite plus que d’apprendre de nouvelles commandes. Pour prendre en charge le développement distribué, Git stocke l’historique des fichiers et les informations de branche différemment d’un système de contrôle de version centralisé. La planification et l’implémentation d’une migration réussie vers Git à partir d’un système de contrôle de version centralisé nécessite de comprendre ces différences fondamentales.

Microsoft a aidé à migrer de nombreuses équipes internes et clients des systèmes de contrôle de version centralisés vers Git. Cette expérience a produit les instructions suivantes basées sur les pratiques qui réussissent constamment.

Étapes de migration réussie

Pour une migration réussie, les équipes doivent :

  • Évaluez les outils et processus actuels.
  • Sélectionnez une stratégie de branchement Git.
  • Déterminez si et comment migrer l’historique.
  • Conservez le système de contrôle de version précédent.
  • Supprimez les fichiers binaires, les exécutables et les outils du contrôle de code source.
  • Former des équipes dans les concepts et pratiques Git.
  • Testez la migration vers Git.

Évaluer les outils et processus actuels

La modification des systèmes de contrôle de version interrompt naturellement le flux de travail de développement avec de nouveaux outils et pratiques. Cette interruption peut être l’occasion d’améliorer d’autres aspects du processus DevOps.

Teams doit envisager d’adopter les pratiques suivantes lors de leur migration vers le nouveau système :

  • Intégration continue (CI), où chaque commit déclenche une compilation et une exécution de tests. CI permet d’identifier les défauts précoces et de fournir un filet de sécurité solide pour les projets.

  • Révisions de code requises avant la vérification du code. Dans le modèle de branchement Git, la révision du code de demande de tirage fait partie du processus de développement. Les révisions de code complètent le flux de travail CI.

  • Livraison continue (CD) pour automatiser les processus de déploiement. La modification des outils de contrôle de version nécessite des modifications de processus de déploiement. Une migration est donc un bon moment pour adopter un pipeline de mise en production moderne.

Sélectionner une stratégie de branchement Git

Avant de migrer du code, l’équipe doit sélectionner une stratégie de branchement.

Dans Git, les branches de rubriques de courte durée permettent aux développeurs de travailler près de la branche principale et d’intégrer rapidement, ce qui évite les problèmes de fusion. Deux stratégies courantes de branche de rubrique sont GitFlow et une variante plus simple, GitHub Flow.

Git décourage les branches de fonctionnalités isolées, qui ont tendance à retarder les fusions jusqu’à ce que l’intégration devienne difficile. En utilisant des techniques cd modernes telles que des indicateurs de fonctionnalité, les équipes peuvent intégrer du code dans la branche principale rapidement, mais conserver les fonctionnalités en cours cachées des utilisateurs jusqu’à ce qu’elles soient terminées.

Les équipes qui utilisent actuellement une stratégie de branche de fonctionnalités de longue durée peuvent adopter des indicateurs de fonctionnalité avant de migrer vers Git. L’utilisation d’indicateurs de fonctionnalités simplifie la migration en minimisant le nombre de branches à migrer. Qu’elles utilisent des branches de fonctionnalités ou des indicateurs de fonctionnalité, les équipes doivent documenter le mappage entre les branches héritées et les nouvelles branches Git, afin que tout le monde comprenne où valider son nouveau travail.

Décider s’il faut migrer l’historique

Les équipes peuvent être tentées de migrer leur historique de code source existant vers Git. Plusieurs outils prétendent migrer un historique complet de toutes les branches d’un outil centralisé vers Git. Une validation Git semble correspondre relativement bien au modèle d'ensemble de modifications ou d'enregistrement utilisé par l'outil de contrôle de version précédent.

Toutefois, ce mappage présente des limitations sérieuses.

  • Dans la plupart des systèmes de contrôle de version centralisés, les branches existent en tant que dossiers dans le référentiel. Par exemple, la branche principale peut être un dossier nommé /trunk, et d’autres branches sont des dossiers tels que /branch/one et /branch/two. Dans un référentiel Git, les branches incluent l’intégralité du référentiel, de sorte qu’une traduction 1:1 est difficile.

  • Dans certains systèmes de contrôle de version, une étiquette ou une étiquette est une collection qui peut contenir différents fichiers dans l’arborescence, même des fichiers à différentes versions. Dans Git, une étiquette est un instantané de l’ensemble du référentiel à un moment donné. Une balise ne peut pas représenter un sous-ensemble du référentiel ni combiner des fichiers à différentes versions.

  • La plupart des systèmes de contrôle de version stockent des détails sur la façon dont les fichiers changent entre les versions, y compris les types de modifications affinés tels que renommer, annuler la suppression et restaurer. Git stocke les versions sous forme d’instantanés de l’ensemble du référentiel et les métadonnées sur la façon dont les fichiers modifiés ne sont pas disponibles.

Ces différences signifient qu’une migration complète de l’historique sera perdue au mieux, et éventuellement trompeuse. Compte tenu de la perte, de l’effort impliqué et de la rareté relative de l’utilisation de l’historique, il est recommandé que la plupart des équipes évitent d’importer l’historique. Au lieu de cela, les équipes doivent effectuer une migration du sommet, en mettant uniquement un instantané de la version de branche la plus récente dans Git. Pour la plupart des équipes, le temps est le mieux passé sur les domaines de la migration qui ont un retour sur investissement plus élevé, comme l’amélioration des processus.

Gérer l’ancien système de contrôle de version

Pendant et après une migration, les développeurs peuvent toujours avoir besoin d’accéder à l’historique de contrôle de version précédent. Bien que l’historique de contrôle de version précédent devienne moins pertinent au fil du temps, il est toujours important de pouvoir y faire référence. Les environnements hautement réglementés peuvent avoir des exigences légales et d’audit spécifiques pour l’historique des contrôles de version.

En particulier pour les équipes qui effectuent uniquement une migration de la pointe, il est fortement recommandé de maintenir indéfiniment le système précédent. Définissez l’ancien système de contrôle de version sur lecture seule après la migration.

Les équipes de développement volumineuses et les environnements réglementés peuvent placer des barres de navigation dans Git qui pointent vers l’ancien système de contrôle de version. Un exemple simple est un fichier texte ajouté en tant que première validation à la racine d’un dépôt Git, avant la migration de la pointe, qui pointe vers l’URL de l’ancien serveur de contrôle de version. Si de nombreuses branches migrent, un fichier texte dans chaque branche doit expliquer comment les branches ont migrées à partir de l’ancien système. Les barres de navigation sont également utiles pour les développeurs qui commencent à travailler sur un projet après sa migration et ne connaissent pas l’ancien système de contrôle de version.

Supprimer des fichiers binaires et des outils

Le modèle de stockage git est optimisé pour le contrôle de version des fichiers texte et du code source, qui sont compacts et hautement compressibles. Les fichiers binaires sont généralement volumineux et une fois qu’ils sont ajoutés à un référentiel, ils restent dans l’historique du référentiel et dans chaque clone futur. En raison de la façon dont Git stocke l’historique, les développeurs doivent éviter d’ajouter des fichiers binaires à des référentiels, en particulier des fichiers binaires très volumineux ou qui changent souvent. La migration vers Git est l’occasion de supprimer ces fichiers binaires de la base de code.

Il est également recommandé d’exclure des bibliothèques, des outils et les résultats de la compilation des référentiels. Utilisez plutôt des systèmes de gestion de package comme NuGet pour gérer les dépendances.

Les ressources telles que les icônes et les illustrations peuvent avoir besoin d’être alignées avec une version spécifique du code source. De petites ressources rarement modifiées comme les icônes ne gonflent pas l’historique et vous pouvez les inclure directement dans un référentiel. Pour stocker des ressources volumineuses ou fréquemment changeantes, utilisez l’extension De stockage de fichiers volumineux (LFS) Git. Pour plus d’informations sur la gestion des fichiers volumineux dans GitHub, consultez Gestion des fichiers volumineux. Pour Azure Repos, consultez Gérer et stocker des fichiers volumineux dans Git.

Fournir une formation

L’un des principaux défis de la migration vers Git est d’aider les développeurs à comprendre comment Git stocke les modifications et comment les validations forment l’historique du développement. Il ne suffit pas de préparer un aide-mémoire qui associe les anciennes commandes aux commandes Git. Les développeurs doivent cesser de réfléchir à l’historique des contrôles de version en termes de modèle centralisé, linéaire et comprendre le modèle d’historique de Git et le graphique de validation.

Les gens apprennent de différentes façons. Vous devez donc fournir plusieurs types de supports de formation. La formation en laboratoire en direct avec un instructeur expert fonctionne bien pour certaines personnes. Le livre Pro Git est un excellent point de départ disponible gratuitement en ligne.

Les cours de formation pratiques disponibles sont les suivants :

Les organisations doivent travailler pour identifier les experts Git sur les équipes, leur permettre d’aider d’autres personnes et encourager les autres membres de l’équipe à leur poser des questions.

Tester la migration

Une fois que les équipes mettent à jour leurs processus, analysent leur code et entraînent leurs membres, il est temps de migrer le code source. Que vous effectuiez une migration de pointe ou une migration de l'historique, il est important de faire une ou plusieurs migrations de test dans un référentiel de test. Avant d’effectuer une migration finale, assurez-vous que :

  • Tous les fichiers de code migrent.
  • Toutes les branches sont disponibles.
  • Il n’y a pas de binaires errants dans le référentiel.
  • Les utilisateurs disposent des autorisations appropriées pour extraire et envoyer (push).
  • Les builds réussissent et tous les tests réussissent.

Migrer le code

Effectuez la migration finale pendant les heures non ouvrées, idéalement entre les jalons en cas de temps d’arrêt naturel. La migration à la fin d’un sprint peut entraîner des problèmes pendant que les développeurs tentent de terminer le travail. Essayez de migrer pendant un week-end, quand personne n’a besoin de s’enregistrer.

Planifiez un basculement ferme entre l’ancien système de contrôle de version et Git. Essayer d’exploiter plusieurs systèmes en parallèle signifie que les développeurs ne savent peut-être pas où ou comment s’enregistrer. Définissez l’ancien système de contrôle de version sur lecture seule pour éviter toute confusion. Sans cette protection, une deuxième migration incluant des modifications intermédiaires peut être nécessaire.

Le processus de migration réel varie en fonction du système à partir duquel vous effectuez la migration. Pour plus d’informations sur la migration à partir de Team Foundation Version Control, consultez Migrer de TFVC vers Git.

Liste des éléments à vérifier pour la migration

Flux de travail d’équipe :

  • Déterminez la manière dont les builds se dérouleront.
  • Déterminez quand les tests s’exécuteront.
  • Développez un processus de gestion des mises en production.
  • Déplacer les révisions de code vers les requêtes de tirage.

Stratégie de branchement :

  • Choisissez une stratégie de branchement Git.
  • Documentez la stratégie de branchement, pourquoi elle a été sélectionnée et comment les branches héritées sont mappées.

History:

  • Décidez de la durée pendant laquelle le système de contrôle de version ancien doit rester opérationnel.
  • Identifiez les branches qui doivent être migrées.
  • Si nécessaire, créez des barres de navigation pour aider les ingénieurs à revenir au système hérité.

Fichiers binaires et outils :

  • Identifiez les fichiers binaires et les fichiers non diffables à supprimer du dépôt.
  • Choisissez une approche pour les fichiers volumineux, tels que Git-LFS.
  • Choisissez une approche pour fournir des outils et des bibliothèques, tels que NuGet.

Formation:

  • Identifiez les supports de formation.
  • Planifiez des événements de formation, des documents écrits et des vidéos.
  • Identifiez les membres de l’équipe pour servir d’experts Git locaux.

Migration du code :

  • Effectuez plusieurs exécutions de test pour vous assurer que la migration sera fluide.
  • Identifiez et communiquez un délai de basculement.
  • Créez le nouveau dépôt Git.
  • Définissez l’ancien système en lecture seule.
  • Migrez d’abord la branche principale, puis toutes les autres branches nécessaires.

Étapes suivantes

  • Last updated on