A step-by-step guide to migrating from Perforce to Git
Comme nous l'avons expliqué dans l'article précédent, Git est désormais le choix de facto des SCM pour tout type de développement digital. Mais si vous avez un précieux historique de plusieurs années dans Perforce, vous réfléchissez probablement au coût de cette transition. Dans cet article, nous allons aborder ces problèmes de front et nous vous expliquerons comment migrer des données vers Git. Nous avons décomposé le processus de migration de Perforce vers Git en huit étapes :
- Migration de données Perforce
- Mappage des utilisateurs et permissions vers un nouveau dépôt Git
- Fichiers binaires volumineux
- Dépendances complexes
- Structuration de votre équipe durant la migration
- Données mises en miroir
- Outils ALM
- Comment définir la réussite après une migration de Perforce vers Git
Étape 1 : Migration de données Perforce
Il existe deux approches pour migrer des données de Perforce vers Git. Avant de nous plonger dans ce sujet, nous devons considérer une différence fondamentale dans la façon dont Perforce et Git gèrent les projets logiciels.
Un serveur Perforce peut contenir des dizaines ou des centaines de projets logiciels distincts, chacun avec son propre modèle de branching. Un développeur définit une « vue » qui indique au serveur Perforce quels fichiers placer dans une copie de travail. D'un autre côté, un dépôt Git ne contient normalement qu'un seul projet logiciel avec ses branches et tags (bien qu'il existe de grands dépôts Git monolithiques). Généralement, vous clonez le dépôt puis, éventuellement, vous vérifiez les submodules ou les subtrees.
La question du déplacement des données est double : comment extraire les données de Perforce et comment les traduire en un ensemble équivalent de dépôts Git.
Option 1 de migration des données Perforce : utiliser Git Fusion
Si vous souhaitez conserver l'intégralité de l'historique de vos données dans Perforce, vous pouvez utiliser l'outil Git Fusion de Perforce pour extraire une section d'un serveur Perforce (un seul projet) dans un dépôt Git. Essentiellement, vous :
Ressource connexe
Comment déplacer un dépôt Git complet
DÉCOUVRIR LA SOLUTION
Découvrir Git avec Bitbucket Cloud
- Installer Git Fusion
- Définissez des vues correctes de vos données, y compris la structure de branches.
- Utilisez le client Git de votre choix pour effectuer un clonage à partir de Git Fusion
- Pushez votre dépôt dans Bitbucket
Hands-on example *In order to work through this example you’ll need a Perforce server with Git Fusion already operational.* Let’s say that you have a Perforce project living in the repository path //depot/acme/… (in Perforce depot view syntax). It has three branches: - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… Keep in mind that with Perforce you see branches as additional directories in the tree. Your first step is to configure Git Fusion so that it understands the branching relationship in Perforce. To do this, you create a repo configuration file: [@repo] description = Acme project charset = utf8 [main] git-branch-name = main view = //depot/acme/main/… … [r1.0] git-branch-name = r1.0 view = //depot/acme/r1.0/… … [r1.1] git-branch-name = r1.1 view = //depot/acme/r1.1/… … Submit this file to Perforce under the path //.git-fusion/repos/acme/p4gf_config Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, clone from Git Fusion: git clone https:///acme cd acme git remote add bitbucket git push –u --all bitbucket git push --tags Bitbucket That’s it! You should now see the imported history in Bitbucket.Il se peut toutefois que vous n'obteniez pas une copie 100 % conforme à vos données Perforce. Certaines opérations Perforce, comme les merges partiels, n'ont pas d'équivalent dans Git. Mais, dans l'ensemble, cette méthode récupérera l'essentiel de votre historique sans trop de difficultés.
Gardez à l'esprit que la conservation des dix dernières années d'historique de branching à partir d'un SCM existant n'implique pas que vous continuiez à utiliser le même workflow. Comme première étape pratique, vous devriez notamment envisager d'adopter des workflows de branche de fonctionnalité tels que Gitflow.
Avantages et inconvénients
- Nécessite le plus de travail de configuration et d'exécution
- Conserve le plus d'historique possible (vous permettant de fermer le serveur Perforce existant)
- Conserve le modèle de branching hérité dans l'historique
Option 2 de migration des données Perforce : recommencer de zéro
L'autre option consiste à recommencer. Oubliez toute cette histoire croustillante : il suffit d'extraire la pointe (head) de chaque branche de Perforce qui correspond à votre projet et de la vérifier dans un nouveau dépôt Git vide. (Cela implique de définir des espaces de travail Perforce avec une « vue » correcte des données que vous souhaitez.)
C'est la technique la plus simple et la plus rapide. Peu importe le degré de complexité qu'avait votre historique Perforce, votre nouveau dépôt Git est épuré et simple. Vous avez une opportunité de démarrer un nouveau workflow basé sur Git, sans bagage superflus.
Le principal inconvénient ? Vous voudrez probablement garder votre ancien serveur Perforce en mode lecture seule au cas où quelqu'un aurait besoin d'effectuer des recherches dans le code historique pour une raison quelconque. Cela ne vous coûtera rien en frais de licence, mais implique que vous mainteniez en vie ce vieux serveur pendant un certain temps.
**Hands-on example** Go into your Perforce workspace (the directory where the main branch of your project data is checked out) and run: p4 sync This fetches the latest revision of your files. Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, create a new Git repo in your workspace and push to Bitbucket: git init . git remote add origin git push –u --all origin git push --tags origin You should now see the latest snapshot of your code as the first commit in your new Bitbucket project.Avantages et inconvénients
- Rapide et simple
- Refonte du modèle de branching et du workflow
- Serveur Perforce existant utilisé pour l'accès en lecture seule
Étape 2 : Utilisateurs et permissions
Après la migration des données, la prochaine tâche consiste généralement à mapper vos utilisateurs et vos permissions dans les nouveaux projets Bitbucket. Si vous utilisez LDAP comme annuaire utilisateurs, vous gagnerez du temps. Dans le cas contraire, vous pouvez facilement extraire un ensemble de comptes utilisateur de Perforce avec la commande p4 users –o, puis les entrer dans Bitbucket projet par projet.
Traduire les permissions Perforce en permissions Bitbucket équivalentes peut s'avérer difficile, étant donné que les premières sont granulaires et complexes et permettent d'exclure l'accès à certains fichiers. Ce schéma de permission complexe est l'une des raisons pour lesquelles un serveur Perforce peut être paralysé. Toute tentative d'accès peut pousser le serveur à effectuer un calcul onéreux sur une structure de données complexe.
Dans la plupart des cas, il est plus rapide de demander aux responsables de projets de définir un ensemble d'autorisations plus simple dans Bitbucket en utilisant les autorisations normales de projet, de dépôt et de branche. En effet, vous aurez de toute façon envie de revoir votre configuration d'autorisations, car Git offre tant de nouvelles options de workflow. Par exemple, dans Perforce, vous pouvez avoir une création de branche restreinte, tandis que dans Bitbucket, il se peut que vous ayez seulement besoin de restreindre l'accès push à la branche main.
Étape 3 : Fichiers binaires
Si vous avez stocké des blobs binaires importants dans Perforce, réfléchissez avec soin à la façon dont vous souhaitez gérer ces derniers dans Git. Vous pouvez essayer Git LFS ou bien simplement utiliser un système de gestion d'artefacts classique. Dans tous les cas, vous ne voudrez certainement pas pusher aveuglément des blobs importants dans un dépôt Git.
Étape 4 : Dépendances complexes
A Perforce working copy may actually map in read-only copies of data from several modules. In Git, this is done either using submodules, subtrees, or by leveraging CI/CD or artifact management systems. There’s no easy answer here, but some data import tools can model a submodule relationship between Git repos. For a more in depth look on how to use submodules or subtrees, you can read about each here: https://www.atlassian.com/git/tutorials/git-subtree.
Étape 5 : Comment structurer votre équipe durant la migration ?
Votre serveur Perforce contient donc 100 projets de 10 équipes. Vous avez préparé une stratégie de migration et un outil. Planifiez la fenêtre de maintenance, et c'est parti !
Euh… non.
N'oubliez pas que la migration des outils SCM concerne autant les développeurs que les données. Vous devez tenir compte des personnes, des processus et de la planification : ne vous précipitez pas. C'est trop risqué.
Vous devez tenir compte d'un plan de projet durant la phase de migration réelle. (C'est peut-être le bon moment pour essayer un nouveau workflow Jira…). Voici quelques options que vous pouvez envisager.
- Migrez équipe par équipe et projet par projet. Essayez de démarrer un projet et une équipe au début d'un sprint ou d'un incrément de programme, quand vous avez du temps pour vous adapter.
- Migrez de manière incrémentielle. Importez toutes vos données en un week-end, puis laissez les équipes terminer peu à peu la migration vers Git. Récoltez périodiquement les deltas en réexécutant vos outils d'importation. Bien que plus complexe, cette stratégie n'est pas mauvaise en cas de dépendances entre les équipes et lorsque les premiers adoptants ont besoin d'au moins un instantané récent dans Git pour alimenter leur pipeline CI/CD.
- Utilisez les deux systèmes à la fois pendant quelque temps. Bien que ce ne soit pas pour les âmes sensibles, il est techniquement possible d'utiliser Git Fusion pour effectuer un échange de données bidirectionnel tant que vous ne faites pas d'opérations complexes susceptibles de perturber le traducteur de données.
Enfin, prenez le temps de communiquer les changements à l'équipe : la motivation, les raisons et la marche à suivre. Formez une équipe de « partisans précoces » comprenant des ingénieurs expérimentés en matière de cycle de vie du développement et assurez-vous que cette équipe soit un modèle pour les autres. Recherchez des champions Git pour aider les personnes en difficulté. Apporter des changements mineurs, compréhensibles et itératifs contribuera à la réussite de ce processus.
Step 6: Mirrors and clusters
Perforce a un système simple mais efficace pour mettre en miroir des données vers des sites distants afin de réduire l'effet de la latence. Il dispose d'un système plus complexe pour exécuter un ensemble de miroirs locaux pour la mise en cluster en lecture seule. Bien que la latence ne soit pas vraiment un problème pour Git, si vous gérez une opération à l'échelle internationale, vous devriez envisager d'utiliser Bitbucket Data Center pour la mise en cluster et la mise en miroir, ce qui accélérera grandement vos heures de clonage pour une équipe globale.
Step 7: ALM tools
Et maintenant, une bonne nouvelle : lors de votre migration de Perforce vers Git, vous avez bénéficié de nombreux choix pour votre suite ALM. Presque tous les développeurs et les outils ALM utilisent Git, et il va de soi que Bitbucket permet une intégration parfaite à Jira et Bamboo. Lorsque vous passez à Git, vous pouvez explorer les fonctionnalités Bamboo, comme la planification de branches, qui s'accompagnent d'un workflow de branche de fonctionnalité.
Étape 8 : Définition de la réussite
Alors, comment mesurez-vous exactement le succès d'une migration de Perforce vers Git ? Dans de nombreux projets de migration, nous avons trop tendance à nous concentrer sur la fidélité du transfert de données. Mais, pour de nombreuses raisons, ce n'est pas un indicateur utile. Il est probable que vous ne puissiez jamais obtenir dans Git un historique équivalent au bit près à celui que vous aviez dans un système SCM centralisé comme Perforce.
Une approche plus pratique consiste à utiliser la CI/CD pour effectuer les vérifications. Lorsque vous avez migré votre pipeline CI/CD de Perforce vers Git, tous vos tests sont-ils toujours transférés ? Et pouvez-vous toujours déployer votre logiciel ? Si vos anciens builds importants peuvent toujours être transférés via votre pipeline CI/CD, vous pouvez crier victoire !
C'est fini
À présent, vous avez vu pourquoi les équipes migrent de Perforce vers Git, et comment procéder pour cela. La prochaine étape consiste à choisir une solution Git. Si vous migrez depuis une solution Perforce pour le développement de jeux, découvrez pourquoi les développeurs de jeux vidéos aiment Bitbucket.
Partager cet article
Thème suivant
Lectures recommandées
Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.
Le blog Bitbucket
Parcours de formation DevOps
