Un guide pas-à-pas pour migrer de Perforce vers 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 :

• 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

 Exemple pratique *Pour travailler sur cet exemple, vous aurez besoin d'un serveur Perforce avec Git Fusion déjà opérationnel.* Imaginons que vous ayez un projet Perforce au chemin de dépôt suivant : //depot/acme/… (dans la syntaxe de la vue de dépôt Perforce). Ce projet contient trois branches : - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… N'oubliez pas qu'avec Perforce, vous voyez les branches comme des répertoires supplémentaires dans l'arborescence. La première étape consiste à configurer Git Fusion pour qu'il comprenne la relation de branching dans Perforce. Pour cela, créez un fichier de configuration de dépôt : [@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/… … Soumettez ce fichier à Perforce sous le chemin //.git-fusion/repos/acme/p4gf_config Créez à présent un projet vide appelé acme dans Bitbucket à l'aide des outils d'administration Bitbucket habituels. Vous pouvez configurer le contrôle d'accès et les membres de l'équipe en fonction de vos normes habituelles. Ensuite, effectuez un clonage depuis Git Fusion: git clone https:///acme cd acme git remote add bitbucket  git push –u --all bitbucket git push --tags Bitbucket Et voilà ! Vous devriez désormais voir l'historique importé dans 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.

 **Exemple pratique** Accédez à votre espace de travail Perforce (le répertoire dans lequel la branche main de vos données de projet est extraite) et exécutez : p4 sync Cela récupère la dernière révision de vos fichiers. Créez maintenant un projet vide nommé acme dans Bitbucket en utilisant les outils d'administration Bitbucket habituels. Vous pouvez configurer le contrôle d'accès et les membres de l'équipe en fonction de vos normes habituelles. Ensuite, créez un dépôt Git dans votre espace de travail, puis pushez-le dans Bitbucket : git init . git remote add origin  git push –u --all origin git push --tags origin Vous devriez désormais voir le dernier instantané de votre code en tant que premier commit de votre nouveau projet Bitbucket.

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

Une copie de travail Perforce peut être mappée à des copies en lecture seule de données depuis plusieurs modules. Dans Git, cela s'effectue en utilisant des submodules ou des subtrees, ou en exploitant la CI/CD ou les systèmes de gestion des artefacts. Il n'existe aucune réponse simple, mais certains outils de données peuvent modeler une relation de submodule entre les dépôts Git. Pour en savoir plus sur l'utilisation des submodules ou des subtrees, accédez à la page suivante : https://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-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.

Étape 6 : Miroirs et 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.

Étape 7 : Outils ALM

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.