Le Touilleur ExpressLe Touilleur ExpressLe Touilleur ExpressLe Touilleur Express
  • Accueil
  • A propos de l’auteur
  • A propos du Touilleur Express

Riviera Dev : HOW GITHUB USES GITHUB TO BUILD GITHUB

    Home Java Riviera Dev : HOW GITHUB USES GITHUB TO BUILD GITHUB

    Riviera Dev : HOW GITHUB USES GITHUB TO BUILD GITHUB

    Par Nicolas Martignole | Java | 4 commentaires | 20 octobre, 2011 | 0 | 2 776 affichages
         

    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/

    Articles similaires:

    Le code source du CFP de Devoxx France est sur Github Default ThumbnailRiviera Dev : CoffeeScript par Bodil Stokke Default ThumbnailRiviera DEV Node.js Default ThumbnailConférence Riviera DEV à Sophia-Antipolis
    No tags.
    • Avatar
      jocosti 20 octobre 2011 at 17 h 58 min

      chouette article, mais une petite coquille :

      « La règle chez GitHub c’est que le master doit toujours être déplorable. »

      deployable plutôt 😉

    • Avatar
      Stéphan Lascar 20 octobre 2011 at 21 h 00 min

      Vraiment interessant. Je n’en attendais pas moins pour sérieusement me pencher sur git.

      Encore merci pour cet article !

    • Avatar
      JohnLeRouge 20 octobre 2011 at 21 h 25 min

      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)!

    • Avatar
      Mère Teresa 27 octobre 2011 at 16 h 33 min

      Priorities pour la référence manquante, je dirais.

    Recent Posts

    • GitHub Actions : le tueur de Jenkins ?

      Avouez-le : ce titre de blog est super racoleur. J’avais aussi pensé

      15 février, 2021
    • Comment recréer du lien social dans l’Entreprise avec des outils numériques en 2021

      Nous sommes en février 2021 pendant le 3ème confinement lié à la

      10 février, 2021
    • FizzBuzz en Java et Scala (surtout Scala)

      L’exercice FizzBuzz est un petit exercice très simple, à tester par exemple

      9 février, 2021

    Recent Tweets

    •  @fanf42   @doctolib  Oui toussa 😎

      9 hours ago
    •  @Clever_Support  du coup pr l’instant je reste sur le vieux add-on ElasticSearch chez vous sans SSL qui marche (CFP Devoxx)

      10 hours ago
    •  @Clever_Support  et pas forcément possible de désactiver SSL SNI coté client Java :(

      10 hours ago
    •  @Clever_Support  Je galère avec SSL + unrecognized_name (SNI). Testé Java8,Java11, Java15. Testé avec AsynchHttp. Testé avec Elastic4S

      10 hours ago
    •  @Clever_Support  car Elastic4S par exemple fixe à 9200 si le port n’est pas présent https://t.co/4qVv0qVoVu

      10 hours ago

    Mots clés

    agile (18) ajax (11) Apple (11) architecture (6) barcamp (5) BarCampJavaParis (5) ddd (5) devoxx (33) esb (6) exo (6) flex (9) geek (5) google (11) grails (5) groovy (10) humeur (12) humour (7) independant (6) iphone (12) Java (77) javascript (7) jazoon (28) jboss (22) jboss seam (12) jsf (9) jug (16) Linux (11) mac (6) mule (5) parisjug (7) paris jug (22) pjug (6) play (8) playframework (6) portlet (5) recrutement (6) ria (8) Scala (21) scrum (44) spring (23) Startup (11) usi (21) usi2010 (9) web (16) xebia (7)

    Le Touilleur Express

    Contactez-moi : nicolas@touilleur-express.fr

    Suivez-moi sur Twitter : @nmartignole

    Copyright© 2008 - 2020 Nicolas Martignole | Tous droits réservés
    • A propos de l’auteur
    • A propos du Touilleur Express
    Le Touilleur Express