fabernovel loader

Mar 16, 2017 | 7 min de lecture

Tech

Git-Merge : Partie 2 - Conférences

Edouard Siegel

Head of Engineering


FABERNOVEL TECHNOLOGIES
Git Merge 2017 est une conférence de deux jours centrée sur Git qui a eu lieu à Bruxelles début février. Dans un précédent article, nous vous présentions le contenu de la première journée constituée d’ateliers pour utilisateurs Git de tous niveaux. Celui-ci couvre la seconde partie : les conférences. Elles étaient au nombre de neuf, plus trois lightning talks et l’obligatoire discours de bienvenue.

Introduction & Bienvenue

Nous avons été accueillis par la “cyborg” Karen Sandler. Directeur Exécutif de la Software Freedom Conservancy. Elle a une fantastique histoire quant à son intérêt pour l’open source. Ne voulant rien gâcher vous pouvez l’écouter lors de son intervention à la SeaGL 2014 (en anglais)

Top 10 des pires dépôts à héberger sur GitHub

Pour la première conférence, Carlos Martin Nieto, Infrastructure Engineer chez GitHub, est monté sur scène pour nous parler des pires dépôts qu’il a rencontré jusqu’à présent. Comment ils ont résolu les problèmes liés (ou parfois simplement ignoré le problème, et choisi de demander à l’utilisateur de ne pas se servir de GitHub de cette manière), et comment cela mène à des améliorations globales du service.

GitHub eux-même, Kubernetes, CocoaPods, ou encore ce petit dépôt d’étudiant qui teste des scripts et push plusieurs fois par minutes pendant six jours, figurent tous au palmarès.

Sages paroles de Carlos : « Les utilisateurs vont vous surprendre, mais ce n’est pas grave, et parfois il suffit de se parler pour résoudre un problème. »

Mise à l’échelle de Git chez Microsoft

Saeed Noursalehi, Principal Program Manager chez Microsoft a pris la suite, pour nous décrire le contexte actuel chez eux. Factuellement, ils fonctionnent avec un énorme dépôt. On parle ici de 270 Go, 3,5 millions de fichiers, 86 Go pour le pack initial, 400 Mo pour le fichier d’index, et tout ça pour 4000 utilisateurs. N’importe quelle opération basique prend plusieurs minutes (8 pour un status, 30 pour un commit, plusieurs heures pour un checkout…) Leur solution a été de virtualiser le système de fichier sur lequel se base le dépôt. En pratique l’arbre de fichiers est récupéré via JSON, mais le fichier lui-même n’est téléchargé que si nécessaire (si l’on veut l’éditer par exemple).

Ceci a mené à la création de GVFS un outil open source, pour l’instant uniquement disponible sous Windows même s’ils travaillent au portage sur d’autres plateformes.

De quels problèmes souffre Git ?

La dernière présentation de la matinée a été donnée par Santiago Perez de Rosso, PhD Student au MIT. Il centre sa réflexion sur l’affirmation discutable que Git est « facile à apprendre ». Les études disponibles montrent en effet que les utilisateurs sont peu sûrs d’eux, et que toute opération pour corriger les erreurs faites est coûteuses en temps. Il a aussi analysé les questions les plus vues et ayant le plus de votes sur StackOverflow. Ceci l’a amené à la conclusion que ce n’est pas un problème d’interface, mais que la faute se situe vraiment dans les concepts mis en œuvre.

Il s’est alors basé sur une théorie du design centré sur les concepts pour repenser certains composants et comportements de Git pour créer un surcouche nommée Gitless. Gitless est un prototype expérimental. Il a été relativement bien accepté par les utilisateurs novices, mais beaucoup moins par les experts. Cela laisse penser que son approche pourrait être utile. À voir à plus grande échelle.

Git : l’outil que l’on aime, et (parfois) craint

Après la pause déjeuner nous attaquons le prochain groupe de présentation avec Caren Garcia, Implementation Engineer chez BazaarVoice. Elle est aussi assistante pédagogique à l’université du Texas, où elle essaye de propager Git et son utilisation.

Pas grande chose à retenir ici. En substance si vous voulez aider d’autres personnes à apprendre Git, il faut se concentrer sur les bases, bien faire comprendre que rien n’est fatal, et surtout pratiquer énormément. De plus, ohshitgit.com peut être une ressource utile.

Enfin, d’autres industries pourraient bénéficier de Git. Les écrivains, mais aussi le gouvernement ou les législateurs qui pourraient travailler sur des traductions simultanées, et les étudiants évidemment.

Mise à l’échelle de Mercurial chez Facebook : Retour d’expérience

Durham Goode, Tech Lead chez Facebook, a pris la suite. Il avait du feedback intéressant sur leur utilisation de Mercurial. Cette présentation partageait beaucoup de points communs avec la « Mise à l’échelle de Git chez Microsoft ». Ils ont des problèmes à cause de leurs deux énormes dépôts, tout est lent et long. Pour améliorer les performances ils ont alors écrit plusieurs extensions. La plus notable est probablement la virtualisation du système de fichiers avec téléchargement à la volée. Globalement la même logique que ce qui a été mis en place par Microsoft pour Git. Tout ceci n’est malheureusement pas mergé dans Mercurial à date car cela casse la rétrocompatibilité. C’est néanmoins open-source.

Plutôt intéressant, surtout si vous êtes (ou étiez) un utilisateur de Mercurial.

Git LFS à la vitesse de la lumière

Après une courte pause, Lars Schneider, Tech Lead chez Autodesk, est monté sur scène accompagné de Taylour Blau, Infrastructure Engineer chez GitHub. Lars explique comment l’utilisation intensive de Git LFS chez Autodesk l’a confronté à un goulot d’étranglement, et comment ses échanges avec Taylor ont amélioré l’ensemble.

Dans sa partie, Lars décrit comment contribuer à Git même, ce qui peut être un processus assez fastidieux (La revue de code est TRÈS rigoureuse). Taylor nous détaille ensuite le correctif qui a amélioré LFS d’un facteur 80. Dans les grandes lignes, au lieu de dupliquer le process LFS pour chaque fichier à traiter, il est maintenant gardé en vie.

Alias Git des Dieux !

Tim Pettersen, développeur Bitbucket chez Atlassian prend le relais pour nous partager ses connaissances des alias Git. Ceci est d’autant plus important que Git ajoute moult nouvelles fonctionnalités rétro-compatibles, ce qui se traduit par un nombre toujours croissant de commandes et d’options. Les alias aident à améliorer la productivité de l’utilisateur en lui permettant de personnaliser ses commandes favorites. C’est un outil très puissant, puisque cela permet notamment d’appeler des commandes ou un script shell.

Parmi les astuces intéressantes on peut relever la commande daemon de Git qui permet d’exposer son dépôt en read-only. Du coup l’alias `serve = daemon –reuseaddr –verbose –base-path=. –export-all ./.git` peut se révéler utile si son hébergeur rencontre un problème temporaire. À combiner avec ngrok pour le partager avec un utilisateur distant.

Lightning Talks

Trois lightning talks ont suivi la dernière pause de la journée :

  • Tamir Gefen d’ALMtoolbox nous a fait une checklist du nécessaire à prévoir lors d’une transition d’outil de versionning. Mis en pratique lors de la transition d’un de leur client de ClearCase à Git.
  • Meredith Patterson, de Mautinoa Technologies, nous a expliqué comment Git a servi à mettre en place un système de paiement offline sécurisé entre téléphones cellulaires. Chaque utilisateur se voit remettre des clés d’authentification ainsi que deux dépôts équivalents d’un livre comptable historique des transactions réalisées. Les téléphones peuvent alors échanger par infrarouge et se synchroniser plus tard avec le dépôt maître. Elle met l’accent sur l’importance de la créativité pour résoudre autrement des problèmes à l’aide d’outils connus.
  • Santiago Mola, de source(d), nous a finalement présenté leur projet go-git. Ils ont pour but de réaliser la première IA qui comprend le code. Pour cela ils la nourrissent avec les millions de dépôts publics disponibles en ligne. Vu la quantité d’informations à traiter, ils ont alors décidé de réimplémenter Git en Go, leur langage de choix, pour améliorer les performances au maximum.

Git pour le Pair Programming

Pour l’avant-dernière conférence de l’évènement, Cornelius Schumacher, Senior Software Developer chez SUSE Linux a pris le micro pour nous parler du Pair Programming. Après en avoir défini les modalités (comment, pourquoi…) il souligne les limitations de Git dans son cas d’usage. En l’occurrence, les commits n’ont qu’un seul auteur, alors qu’il ferait sens de pouvoir en définir deux lors d’un travail en paire. Son outil, git-duet répond partiellement au problème. Il espère voir le support du multi-auteur s’améliorer prochainement, que ce soit dans les échanges par emails, GitHub ou dans Git même à terme.

Avoir confiance, mais vérifier

Dernière présentation, mais pas des moindres, Thordur Bjornsson, Software Developer chez Yubico, traite le sujet de la signature numérique. Il commence par en décrire les tenants et aboutissants. Pourquoi signer son travail, ce que ça implique, et les outils nécessaires. Il a aussi quelques conseils quant à la gestion des clés de chiffrement, qu’il faut démultiplier, pour compartimenter, et associer à des dates d’expiration courtes, pour minimiser les impacts en cas de fuite.

Il continue avec la description de son workflow idéal, tout en restant relativement raisonnable en terme d’éléments signés. Sans quoi il sait que la transition ne se fera probablement jamais si trop brutale. Globalement il espère voir les mainteneurs signer les commits de merge et les tags, et chaque projet devrait avoir sa propre clé.

Conclusion

Cette seconde journée était dense en conférences présentées par des gens à la passion communicative. Les sujets étaient globalement variés et le rythme et la durée des présentations étaient au point. Dans l’ensemble, nous pensons que cet évènement était un succès, l’organisation était bien rodée, et le choix des intervenants et du contenu présenté tout à fait pertinent. Vivement la prochaine édition !

Nous sommes toujours à la recherche de personnes compétentes.

Rejoignez-nous!
logo business unit

FABERNOVEL TECHNOLOGIES

150 talents pour répondre aux défis technologiques de la transformation digitale.

à lire