Comment les équipes de GitHub utilisent GitHub pour construire GitHub.
Oooh que tu aurais aimé être là avec moi dans la salle, comme quelques 50 privilégiés… Zach Holman est un développeur de chez GitHub. Il commence en expliquant que pour lui, lorsqu’il va à des conférences, il y a toujours un effet étrange. Il vous écoute parler d’Agile, comment Kanban a sauvé votre vie, comment vous vous êtes réconcilié avec votre équipe métier grâce à un Scrum Master… Mais lui n’utilise rien de tout cela. Il utilise GitHub et développe chez GitHub. Et ce développement social a changé la façon dont il travaille. Et il a compris que d’autres moyens existent pour travailler, qui ne sont pas lié à l’Agilité. Le coding social…
GitHub est une société qui travaille de manière asynchrone :you can do shit without needing to pull me out of The Zone.
Pas de meeting, pas de manager et pas de deadlines. Oui vous lisez bien : pas de manager… Si vous bossez mieux l’après-midi, et bien vous bossez l’après-midi. Si vous voulez coder à 2h du matin, et bien vous codez à 2 heures du matin.
Pour travailler, tout le monde utilise des Chatrooms pour travailler. Tout est loggé, donc si vous perdez une discussion vous pouvez revenir dans la discussion. Flexibilité maximale mais très bon outillage.
Pull request et branching :
faire que des branches n’est pas la solution. Dans une entreprise il y a 2 types de développeurs : les développeurs sérieux et les développeurs pourris, qui vont vous casser votre repository. Et lorsque l’on débute avec Git, on est tous des développeurs pourris. Si vos branches sont pourries, ce n’est pas bon signe.
Chez GitHub : un master et une branche pour les corrections, qui est ensuite mergé dans le master. Pas 3 ou 4 branches. Chez GitHub tout le monde peut pusher. Cela évite de devoir micromanager les mauvais développeurs. Ils se retrouvent à devoir apprendre et comprendre Git correctement. La règle chez GitHub c’est que le master doit toujours être déployable. Avec entre 15 et 30 déploiements par jour, les mises en production sont constantes. Oui mon pote, tu lis bien : entre 15 et 30 livraisons par jour. Dans ta face.
Si vous êtes nerveux avec un déploiement, vous pouvez alors déployer vers un environnement de staging. Mais gardez vos branches simples.
Tout le monde peut déployer ? Mais vous êtes dingue ?
Ah mais sur GitHub, vous avez des Pull Requests. Et vous savez comment on dit « Pull Request » en Français ? on dit « Revue de code ». Et vous pouvez discuter, commenter, argumenter et refuser une pull request. Vous pouvez vérifier la qualité du code simplement.
Une pull request c’est une grosse description de sa raison d’être, un paquet de commits, des discussions, bref un échange SOCIAL. Mon dieu, nous allons bientôt comprendre que le métier de développeur est un métier social…
Mais Zach est complètement dans le vrai.
Sur GitHub vous pouvez discuter, faire des diffs et voir l’historique : bien mieux que finalement ce que vous avez aujourd’hui avec votre SCM.
Pull requests : you don’t need to fork anything.
Ce sont des processus asynchrones, qui ne demandent pas de réunions où vous perdez votre temps. Vous êtes notifié lorsque quelqu’un fait une pull request, votre mailbox vous donne des informations intéressantes. Email est finalement votre tableau de suivi.
Les pull requests sont aussi l’historique de votre projet. Rien ne vous empêche de vous en servir comme d’un logback.
RealTime Github
Zach parle ensuite d’un développement qu’il a fait, RealTime for GitHub. Il a codé un web service qui affiche le status des services internes de Git. Il commit, et quelques heures plus tard une designer reprend son code HTML et CSS et fait une belle interface. C’est bien l’aspect collaboratif de la plateforme, où chacun vient compléter le travail de son voisin.
Pull Requests doit être vue comme une proposition de nouveauté et de modification. Vous pouvez discuter et finalement ne pas prendre une pull request.
Construisez un build rapide et simple. Pull Requests is about getting shit done without wasting time.
Pensez à votre workflow, avez-vous besoin de tout ce process ? Zach n’a peut-être pas l’expérience du bon gros bazar Français, particulièrement dans notre capacité à empiler une couche de manager et deux couches de développeurs.
Comment gérer les priorités ?
Pensez à une interface de saisie de bug. Au début vous n’avez que 3 champs. Et puis chacun rajoute son super champ de « priorité » ou « composant affecté » ou encore « tour de poitrine de la testeuse »…. Or on s’en fiche non ?
Chez GitHub il y a un champ « titre » et un champ « description ».
Vous pouvez jouer comme ma fille avec les couleurs et la taille de la police dans le rapport de bug que vous rédigez, mais à part écrire plus gros et en rouge, en quoi votre message est important POUR MOI ?
Zach cite Merlin Mann qui a écrit un article à propos des priorités des emails (référence manquante)
Pensez à votre outil de saisie des bugs et des demandes de changement. Pensez aux champs qui ne sont pas bien utilisés ou inutiles… et regardez vos vieux bugs pour comprendre.
OAuth
Zach est un codeur enthousiaste. Il demande à la salle : combien d’application avez-vous codé dernièrement ? Si vous ne pensez qu’à votre projet du lundi au vendredi, BAM vous avez perdu, vous n’êtes pas développeur. Il montre qu’il est tellement simple de commencer n’importe quel projet sur GitHub, qu’il n’est pas normal de ne pas avoir de projets sur cette plateforme pour tout développeur de la Terre (là c’est toi mon pote).
GitHub offre un moteur d’authentification qui finalement permet de simplement gérer de manière sécurisée, consistante et cool l’authentification de votre application. Ne codez pas de login/password dans votre application web. Regardez OpenID ou OAuth… (comme sur l’eXpress-Board, pub discrète pour mon job board)
Hooks and Hubot
Hubot est un outil qui comprend plus de 275 commandes chez GitHub. Une espèce de concièrge, un Bot qui fait pleins de trucs pour vous. Vous pouvez parler avec Hubot et il sait faire pleins de trucs utiles comme déployer votre application, vous donner des informations. Vous pouvez aussi faire n’importe quoi comme mettre des moustaches sur les photos des personnes du Chat. Bon, ça sert à rien, mais on s’est bien marré.
Hubot est comme un bot IRC qui comprend des commandes. C »est le Siri de GitHub. Hubot connait le status de vos branches. Si vous lui parlez bien il peut vous donner rapidement des informations intéressantes sur votre logiciel.
Zach raconte qu’ils ont aussi ce qu’il appelle « Bug Days » où pendant une journée il faut fixer tous les bugs.
Réfléchissez à ce que vous faites tout le temps. Par exemple créer le compte d’un nouveau sur le projet… Réfléchissez à ce que vous pouvez rendre fun.
Simple Tools and better process = Awesome product
Conclusion
Un bon talk bien radical, peut-être loin de notre réalité, mais qui était présenté avec beaucoup de passion.
GitHub c’est 45 développeurs aujourd’hui. Des développeurs Ruby, Java, Javascript, des dieux de l’exploitation, des designers, mais surtout des passionnés. Des développeurs. Pendant 2 ans il n’y avait pas de bureaux, la société s’est donc structurée autour de cette organisation asynchrone.
Références
Le blog de Zach est intéressant à lire : http://zachholman.com/
chouette article, mais une petite coquille :
« La règle chez GitHub c’est que le master doit toujours être déplorable. »
deployable plutôt 😉
Vraiment interessant. Je n’en attendais pas moins pour sérieusement me pencher sur git.
Encore merci pour cet article !
GIT, le dernier truc à la mode. Une équipe de développeurs (juniors) s’est sentie obligée de l’utiliser pour faire comme les copains dans mon entreprise (vous savez la fameuse « peer pressure »).
Après quelques mois d’utilisation il s’avère que GIT est très complexe à utiliser au quotidien et que les bénéfices que l’équipe en attendait ne sont pas là. La plupart des développeurs ont du mal avec, mais ils peuvent briller aux cocktails.
Bien mesurer l’adéquation de cet outil à son projet avant de s’y lancer (et non vous ne deviendrez pas Linus Torvald même si vous utilisez GIT)!
Priorities pour la référence manquante, je dirais.