Git a 10 ans ! Et qui est mieux placé que Github pour organiser une fête à la hauteur de l’événement ? C’est ce qu’ils ont fait avec cette nouvelle édition de la conférence Git-Merge, dont la dernière s’était tenue à Berlin en 2013.
L’événement se déroulait les 8 et 9 avril dernier. La première journée était dédiée aux formations et aux rencontres, mais nous ne nous intéresserons ici qu’aux conférences de la deuxième journée. L’événement était totalement supporté par Github et ses sponsors Microsoft et Atlassian. L’intégralité des recettes issues des droits d’entrées était reversée à la Software Freedom Conservancy.
Hébergé dans le splendide complexe de la Gaité Lyrique, l’événement est résolument tourné vers le networking, avec de courtes conférences de 30 minutes toutes séparées d’une pause de 15 minutes. On relèvera même l’happy hour de 15h à 16h. Le Git-Merge se veut un anniversaire international, et cela se ressent quand on tend l’oreille dans le salon ou qu’on regarde les noms sur les badges, avec très peu de Français. Un certain niveau d’anglais est requis pour s’insérer dans une discussion, et tout autant pour suivre la journée, vu qu’il n’y aura aucun sous titre ni traduction.
A 10h, les conférences commencent, et le tempo est donné par Scott Chacon, développeur chez @Github et auteur du livre Pro Git, intervenant toute la journée en tant que speakerin, et accessoirement le seul (avec les vigiles) en costard-cravate. Il nous présente brièvement le programme de la journée, et on ne peut que constater qu’on ne parlera pas vraiment de l’utilisation de git par les développeurs, mais plutôt au niveau de l’infrastructure et des problèmes qu’on rencontre avec quand on a de gros dépôts ou fichiers dedans.
Mais passons aux conférences.
Git at Google : Making Big Projects (and Everyone Else) Happy – Dave Borowitz, Google
Et c’est Google qui ouvre le bal, avec ses problématiques propres aux grands : Androïd et ses 700 dépôts, dont la somme constitue plusieurs dizaines de giga-octets. Cela implique des soucis évidents de performances, tant côté utilisateur – 50GO avec une connexion ADSL, c’est long ! – que serveur. Un git clone peut monopoliser 100 % du CPU pour le calcul des données à envoyer, et multiplié par xxxxx utilisateurs, cela représente beaucoup de CPU et plusieurs TOs de données par jour. Dave Borowitz aborde l’usage de différentes technique pour rendre exploitable son infrastructure :
- Git LFS
- Shallow Clones
- JGit DFS
- Bundles : clones statiques via https (aucune charge serveur, reprise de téléchargement possible)
Teaching People Git – Emma Jane Hogbin Westby
Conférence surprenante d’Emma Jane, qui forme les gens à l’usage des gestionnaires de version depuis plus de 10 ans, et qui nous livre un retour d’expérience sur la difficulté d’apprentissage et d’enseignement de Git. Elle insiste bien sur le fait qu’il faut absolument éviter la déclinaison de commandes Git, mais mettre les élèves au centre de l’attention, en leur faisant détailler leur workflow de travail, leurs habitudes, et comment les améliorer en utilisant Git. Et le rappel ultime : Git, ce n’est pas simple à apprendre !
Great Artists Steal : Adding Git Support to Microsoft Visual Studio – Edward Thomson, Microsoft
Edward Thomson travaille chez Microsoft, et s’occupe notamment de la partie Visual Studio Online, et Team Foundation Server, le gestionnaire de versions made by Microsoft. Il nous a raconté les processus par lesquels ils sont passés pour migrer la plateforme Online de TFS vers Git, autant au niveau de l’idéalogie « et si on recréait une librairie ? », pour finalement utiliser les outils Open Source et devenir des contributeurs importants dans la communauté.
Beyond Source Code Versioning – Dirk Lehmann, SAP
Dirk Lehmann nous décrit le workflow utilisé sur un projet SAP pour le site de covoiturage twogo. Au final, on est proche du git flow, couplé à un Jenkins pour de la délivrance continue.
Scaling Git at Twitter – Wilhelm Bierbaum, Twitter
Chez Twitter, on ne s’embête pas avec Git : on n’a qu’un seul dépôt, qui contient tout, comme ça on a une vision globale de ce qu’on modifie et on trace facilement les impacts entre les différents systèmes. Inconvénients : ça fait un « Big fat monolithic repository » de plusieurs dizaines de GO, ce qui implique des commandes locales lentes (status, checkout) à cause du grand nombre d’objets, ça prend de la place, et les push/pull peuvent échouer car le dépôt bouge beaucoup. Du coup ils ont développé en interne pas mal de solutions de contournements :
- nouveau système de tracking des modifications des fichiers
- nouveau format des index avec un algorithme de hashing plus performant
- pleins de serveur Git en lecture seule
- Les fetch envoient des diffs par rapport à une date plutôt que de recalculer par rapport à la position de l’utilisateur.
Building a Git Extension with First Principles – Rick Olson, GitHub
Ca commençait à manquer, voici la touche de Github (qui rappelons-le, organise l’événement. Jusqu’ici Github limitait les fichiers de plus de 100mo sur sa plateforme, car ils posent des problèmes de performances et d’historisation. Pour contourner ça, Rick Olson profite du Git-Merge pour annoncer sa nouvelle fonctionnalité : le Git LFS (déjà évoqué par Google). Le principe, c’est de ne plus stocker les fichiers désirés (typiquement les gros binaires) dans le dépôt, mais de les envoyer sur un serveur statique non-git, et de stocker dans git une référence à ceux-ci. Le dépôt n’est pas pollué, on peut historiser, et c’est quasi transparent pour l’utilisateur qui n’a qu’à dire quoi tracker (via des masques : *.psd), et tout le reste se passe en hook de post commit.
The Challenge of Monorepos : Strategies from git-core and open source – John Garcia, Atlassian
Chez Github, on est cool, du coup on se permet même d’inviter la concurrence pour participer à la fête. Et là où c’est ironique, c’est quand Bitbucket passe juste après Github pour présenter (à peu de chose près) la même conférence : on parlera (encore !) ici de stockage de gros fichiers sur la plateforme. La solution proposée est (un peu) moins élégante que Github, puisque les pull/push de gros fichiers se font via une commande séparée, git lob.
Infrastructure as Code : Manage your architecture with Git – Danilo Poccia, Amazon
Pour changer un peu, on nous parle d’infrastructure. Mais pas d’une infra pour faire tourner Git, mais de Git pour faire tourner une Infra. Fort de sa ligne AWS, Amazon propose désormais de gérer ses configurations serveurs via des fichiers json stockés dans git. Modifiez le fichier, pushez, et votre infrastructure se met à jour sous vos yeux, sans rien toucher d’autre. Ca ressemble beaucoup à ce qu’on peut faire avec leur API, mais le gros avantage de Git, c’est que c’est un outil de versionning. Du coup, on peut relier une infra à une version de l’application, et c’est assez précieux pour déployer des environnements de tests (une branche peut être liée à un environnement). Tout cela utilise l’outil AWS Elastic Beanstalk, qui vient sur votre machine avec l’eb line command, qui interprétera votre fichier au format Cloud Formation.
Et c’est fini ! Github ne s’est pas moqué de nous, et ceux qui ont parcouru plusieurs milliers de kilomètres pour cette unique conférence mondiale ne l’ont pas fait pour rien : des orateurs de haut niveau, des sujets forts intéressants et globalement bien traités, une organisation aux petits oignons, tout est fait pour qu’on s’y sente bien, avec un cadre agréable, un Wifi performant, des canapés, le bar, l’ambiance était là, ainsi que la qualité.
