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

  • Article

La migration d’une équipe vers Git à partir du contrôle de version centralisé nécessite plus que simplement 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 la mise en œuvre 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 conseils suivants basés sur des pratiques qui réussissent constamment.

Étapes pour migration réussie

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

  • Évaluer les outils et processus actuels.
  • Sélectionner une stratégie de branchement Git.
  • Déterminer si et comment migrer l’historique.
  • Conserver le système de contrôle de version précédent.
  • Supprimer les fichiers binaires, les exécutables et les outils du contrôle de code source.
  • Former des équipes dans les concepts et pratiques Git.
  • Tester 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.

Les équipes devraient envisager d’adopter les pratiques suivantes à mesure qu’elles migrent vers le nouveau système :

  • Intégration continue (CI), où chaque archivage déclenche une build et une passe de test. CI aide à identifier les défauts précoces et fournit 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, de sorte qu'une migration est 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 étroitement avec la branche principale et de s’intégrer rapidement, évitant ainsi 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 et de longue durée, 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, tout en gardant les fonctionnalités en cours cachées aux 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 pourraient ê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 de modification 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 dépôt. Par exemple, la branche principale peut être un dossier nommé /tronc, et d’autres branches sont des dossiers tels que /branche/une et /branche/deux. Dans un dépôt Git, les branches incluent l’intégralité du dépôt, de sorte qu’une traduction 1:1 est difficile.

  • Dans certains systèmes de contrôle de version, une balise ou étiquette est une collection qui peut contenir différents fichiers dans l’arborescence, même des fichiers à différentes versions. Dans Git, une balise est un instantané de l’ensemble du dépôt à un moment spécifique. Une balise ne peut pas représenter un sous-ensemble du dépôt 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 dépôt 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 astuce de migration, 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.

Maintenir 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 s’y référer. 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 astuce de migration, il est vivement 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 grandes équipes de développement 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 l'astuce, 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 qui ne sont pas familiers avec 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 la gestion des versions des fichiers texte et du code source, qui sont compactes et hautement compressibles. Les fichiers binaires sont généralement volumineux et une fois qu’ils sont ajoutés à un dépôt, ils restent dans l’historique du dépôt 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 dépôts, 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 bibliothèques, outils et sortie de génération des dépôts. Utilisez plutôt des systèmes de gestion des packages 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 dépôt. 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 les dépôts Azure, consultez Gérer et stocker des fichiers volumineux dans Git.

Fournir des formations

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 de développement. Il ne suffit pas de préparer un aide-mémoire qui mappe les anciennes commandes aux commandes Git. Les développeurs doivent cesser de penser à 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 labo 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 gratuits disponibles comprennent :

Les organisations doivent travailler pour identifier les experts Git sur les équipes, leur donner les moyens d’aider les autres 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 forment leurs membres, il est temps de migrer le code source. Que vous effectuez une migration d'astuce ou un historique de migration, il est important d’effectuer une ou plusieurs migrations de test dans un dépôt de test. Avant d’effectuer une migration finale, assurez-vous :

  • Tous les fichiers de code migrent.
  • Toutes les branches sont disponibles.
  • Il n’y a pas de binaires errants dans le dépôt.
  • Les utilisateurs disposent des autorisations appropriées pour extraire et envoyer.
  • Les builds sont réussies 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éterminer la façon dont les builds s’exécuteront.
  • Déterminer quand les tests s’exécuteront.
  • Développer un processus de gestion des mises en production.
  • Déplacer des révisions de code pour extraire des demandes.

Stratégie de création de branches :

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

Historique :

  • Décider de la durée d’exécution du contrôle des versions héritées.
  • Identifier les branches qui doivent migrer.
  • Si nécessaire, créer des barres de navigation pour aider les ingénieurs à revenir au système hérité.

Fichiers binaires et outils :

  • Identifier les fichiers binaires et les fichiers non différenciables à supprimer du dépôt.
  • Décider d'une approche pour les fichiers volumineux, tels que Git-LFS.
  • Décider d'une approche pour livrer des outils et des bibliothèques, tels que NuGet.

Formation :

  • Identifier les supports de formation.
  • Planifier des événements de formation, des supports écrits et des vidéos.
  • Identifier les membres de l’équipe qui serviront d’experts Git locaux.

Migration de code :

  • Effectuer plusieurs exécutions de test pour vous assurer que la migration se déroulera correctement.
  • Identifier et communiquer un délai de basculement.
  • Créer le nouveau dépôt Git.
  • Définir l’ancien système en lecture seule.
  • Migrer d’abord la branche principale, puis toute autre branche nécessaire.

Étapes suivantes