Perforce to Git: Why make the move

Workflow

Si l'on met de côté tous les gadgets, un outil SCM a pour seul objectif la collaboration : permettre à une équipe de développeurs de travailler sur un ensemble partagé de fichiers logiciels. Git propose un modèle de création de branches simple et à faible intensité de calcul, qui offre divers workflows sympas. Création de branches task, git-flow, dépôts forkés : il existe un workflow rapide et facile d'emploi pour chaque type d'équipe (des projets open source aux développeurs professionnels), ainsi que de puissants outils de revue du code et de collaboration.

Et, Git permet de collaborer facilement au-delà des frontières de l'entreprise, une exigence courante dans le développement interfonctionnel. Même si l'accès réseau physique à un dépôt Git partagé est impossible, les outils de patch et de bundle Git facilitent le partage des données.

D'un autre côté, Perforce conserve un enregistrement de branche par fichier, alors que Git en conserve un par commit. Qu'est-ce que cela signifie ? Eh bien, pour commencer, cela crée beaucoup de métadonnées dans la base de données Perforce dès que vous concevez une branche. Dans les déploiements plus larges, cela contribue à des problèmes de performance, poussant de nombreux administrateurs Perforce à limiter la création de branches.

Imaginez un instant : chaque fois que vous voulez créer une branche task pour tester une nouvelle fonctionnalité, vous devez demander l'autorisation. Si vous ne pouvez pas créer de branche task, il se peut que vous fassiez un check-in de code instable sur la branche main ou que vous attendiez d'avoir tout terminé avant de faire un commit global. Vous perdez tous les avantages des outils de CI/CD sur vos branches task, et vous ne pouvez pas suivre votre avancement de façon granulaire. Résultat ? Vous perdez en productivité, car les développeurs disposent de workflows moins efficaces, ou viennent de commencer à utiliser Git et ne savent pas trop comment merger manuellement leur travail dans Perforce.

Onéreuses, les branches Perforce ne sont pas propices au type de workflow privilégié par la plupart des développeurs. Les branches Perforce sont partagées. Finis donc les branches task privées et le rebasage périodique. Et les algorithmes de merge de Perforce sont très compliqués. Des articles complets ont même été rédigés pour expliquer comment merger des fichiers renommés ou dont les attributs ont été modifiés.

Pourquoi ne pas partager le code entre les serveurs Perforce ? Vous êtes reparti pour partager des fichiers .tar sans historique commun. Le modèle de données Perforce considère les historiques de logiciels comme uniques pour un seul serveur, alors que Git peut facilement cloner et partager l'historique partout.

Dialogue et communauté

Oublions un instant les concurrents commerciaux. Pourquoi Git a-t-il surpassé Mercurial et d'autres solutions concurrentes à moindre coût ? Le dynamisme a une certaine valeur, et Git n'en manque pas. Git a été créé par Linus Torvalds pour résoudre les problèmes de développement décentralisé dans le projet de noyau Linux. C'est désormais l'outil SCM standard pour Linux, Android, OpenStack et la plupart des autres projets open source d'envergure. C'est l'outil de choix des développeurs cools. En tant que responsable du recrutement, vous pouvez partir du principe qu'un nouvel ingénieur est capable de (et souhaitera) travailler avec Git sans formation extensive.

Bien sûr, Git jouit d'une communauté open source dynamique sur laquelle vous pourrez vous appuyer. Git évolue rapidement pour résoudre de vrais problèmes, tandis que de nouvelles fonctionnalités majeures comme Git LFS entrent en scène. Vous pouvez contribuer au projet Git si vous voulez résoudre un bug. De plus, vous nous n'aurez jamais à vous cantonner à un produit commercial avec une feuille de route et un rythme imposés par une entreprise. Pensez au nombre de programmes client Git disponibles : plusieurs interfaces graphiques de bureau performantes, l'intégration Explorateur Windows, des plug-ins pour tous les environnements de développement intégrés (IDE) et des outils de développement.

Interfaces graphiques et outils de développement

À l'origine, la prise en charge de l'interface graphique et des outils Git était quelque peu défaillante. Un obstacle pour les utilisateurs qui préféraient une interface visuelle pour interagir avec leurs dépôts Git. Les collaborateurs en dehors des départements techniques, comme les dessinateurs de jeux vidéos, étaient en particulier exclus. Le plug-in Explorateur Windows de Perforce a fait l'unanimité auprès de ce public.

Mais c'est maintenant du passé, fort heureusement. Les interfaces graphiques comme Sourcetree offrent une expérience « point-and-click », et il existe de nombreuses intégrations Shell pour Git. Bitbucket offre de nombreuses fonctionnalités comme les revues du code, les merges, les pull requests, les forks, la consultation de code en ligne, ainsi que d'autres outils de collaboration. En effet, tous les utilisateurs, des data scientists aux agences créatives, constituent des communautés organisationnelles qui ont recours à la collaboration ouverte rendue possible par Git et Bitbucket.

Les développeurs de jeux vidéos sont un cas à part

Cela dit, qu'est-ce qui empêche certaines communautés, comme les développeurs de jeux vidéos et les chercheurs qui travaillent avec des ensembles de données volumineux, de prendre le train en marche ? Tout dépend du type de données et de la complexité du projet.

Fichiers binaires

Les développeurs de jeux vidéos, en particulier les dessinateurs, doivent travailler avec des objets binaires volumineux, comme des textures et des fichiers audio. Les data scientists peuvent avoir des ensembles de données gigantesques composés de milliards d'événements.

Pour Git, cela pose deux problèmes.

• Ces fichiers ne peuvent être mergés. Un mécanisme de verrouillage centralisé peut s'avérer utile, et Perforce en propose un. (Notez cependant que même un serveur centralisé n'offre un mécanisme de verrouillage que sur une seule branche. Vous devez donc avoir un workflow très restreint pour compter sur cette fonctionnalité.)
• Ces fichiers entraînent un ralentissement de Git, car le dépôt s'agrandit.

Le problème de taille du dépôt est en grande partie résolu par Git LFS, une extension qui permet à Git de traiter des fichiers volumineux tout en déléguant le stockage du fichier à un autre endroit.

Le verrouillage des fichiers doit être examiné sous deux angles. Du point de vue de la gestion des configurations logicielles, Git LFS propose un verrouillage supérieur. Git LFS aide à coordonner le verrouillage des fichiers binaires dans plusieurs branches avec un algorithme qui garantit que vous travaillez sur la dernière version, quelle que soit la branche sur laquelle vous vous trouvez. Les utilisateurs qui travaillent avec des fichiers binaires volumineux disposent ainsi de workflows de branching, alors que ce n'est pas le cas avec le modèle de verrouillage à une branche de Perforce.

Il peut également être utile de considérer le verrouillage des fichiers comme un problème de coordination. Si vous vous apprêtez à travailler sur un composant partagé qui ne peut être mergé, comment allez-vous transmettre l'information à toutes les parties intéressées ? Encore une fois, c'est là que les workflows modernes qui utilisent des pull requests et favorisent la collaboration en temps réel révèlent tout leur intérêt. Vous pouvez rapidement communiquer vos intentions en utilisant Hipchat et vous informer du travail en attente dans un fichier en particulier.

En outre, il est intéressant de s'interroger sur la manière dont le traitement des fichiers volumineux va évoluer à l'ère du Big Data. Afin de tester une tâche d'analyse Big Data, vous aurez peut-être besoin d'un ensemble de données de plusieurs téraoctets. Oubliez l'idée d'un système SCM : ce projet est testé et exécuté sur un système de fichiers compatible avec le Big Data. Ce dont nous avons besoin ici, c'est d'un système d'intégration et de livraison continues qui puisse orchestrer un pipeline plus complexe, avec des artefacts stockés dans un système de fichiers HDFS ou S3. Ce qui nous amène au point suivant.

Projets d'envergure

Le développement d'un jeu est l'exemple type d'un projet intégrant plusieurs modules ou composants : le moteur du jeu, l'interface utilisateur, le fond statique, le rendu vidéo, etc. En tant que dépôt centralisé monolithique, Perforce peut héberger tous ces modules dans un serveur unique et permet à l'utilisateur de choisir les parties sur lesquelles il souhaite travailler.

Cependant, cet avantage est devenu très discutable. Les systèmes Git modernes comme Bitbucket permettent de gérer plus facilement des outils Git multimodulaires comme les submodules et les subtrees. Plus important encore : des projets d'envergure comme Android ont montré la voie à suivre pour gérer des projets complexes à l'aide d'outils de composition de niveau supérieur. Bon nombre de ces enseignements ont servi à enrichir des outils d'intégration et de livraison continues comme Bamboo et Bitbucket Pipelines, qui peuvent orchestrer des workflows d'intégration continue complexes, modéliser les dépendances entre les projets et gérer les artefacts d'un projet à l'autre.

Cette tendance est largement associée à la philosophie Git (et Unix) qui consiste à développer un outil efficace pour une tâche en particulier. L'intégration et la livraison continues (CI/CD) sont des pratiques à part en entière, qui incluent des outils permettant de comprendre des workflows de build et de livraison. Elles s'alignent également sur les bonnes pratiques modernes de développement logiciel, qui visent à utiliser des microservices qui se suffisent à eux-mêmes plutôt que des projets monolithiques.

Étapes suivantes

Le camp qui souhaite une migration de Perforce vers Git fait preuve d'un certain dynamisme. Et, Git et les outils de CI/CD modernes sont désormais prêts à gérer les initiatives de développement les plus larges et les plus complexes. En effet, Perforce a développé un outil appelé Git Fusion qui vous permet d'extraire une partie du dépôt Perforce centralisé au même titre qu'un dépôt Git.

Malheureusement, si Git Fusion représentait un effort méritoire, la tentative de superposer Git à un système SCM centralisé n'est pas une tâche facile ; si vous essayez de combiner vos modèles d'utilisation, vous risquez de corrompre la vue des données d'un système. Si vous n'associez pas vos modèles d'utilisation, il vous sera difficile d'évaluer l'intérêt de placer un back-end centralisé commercial derrière Git. Comme nous l'avons vu, la tendance est à l'inverse : comment intégrez-vous les derniers composants d'un SCM centralisé qui étaient utiles dans Git ?

Si vous utilisez Perforce pour développer un logiciel ou un jeu, vous vous demandez certainement (et nerveusement) comment migrer vers Git. Comment allez-vous faire ? Les coûts de transfert en valent-ils la peine ? Le prochain article se penchera précisément sur ces questions.