Accueil > Divers > QCon London 2012 : « How GitHub Works »

QCon London 2012 : « How GitHub Works »

How gitHub works



Parmi les présentations de QCon London 2012 celle sur l’organisation de GitHub était particulièrement intéressante. Retour sur les secrets de fabrication de la petite startup de San Francisco devenue le réseaux sociaux des développeurs open source.

GitHub a été lancé en avril 2008 et fonctionne depuis le début de façon distribué. En effet, les 4 fondateurs étaient chacun aux quatres coins du monde quand ils ont créés GitHub. Même si leur siège est à San Francisco, GitHub continue de recruter des développeurs partout dans le monde pour s’assurer d’avoir les meilleurs talents. GitHub prend bien soin de garder ses employés “happy”, et apparemment cela fonctionne plutôt bien puisque en 4 ans ils sont désormais 60 et toujours 0 démission.




Travailler de façons asynchrone
facilite aussi le travail distribué. Pour cela, toutes les communications passent par le chat ou les commentaires de pull request. L’idée est de limiter au maximum les réunions et les interruptions pour que les gens restent le plus longtemps possible dans “la zone”. La “zone”, c’est le moment où vous êtes hyper concentré sur une tâche et donc hyper productif. Dans notre métier il est parfois nécessaire d’absorber une importante charge cognitive (lecture et analyse) avant de produire quelques nouvelles lignes de code. Donc inutile d’ajouter des distractions et des interruptions alors qu’il est tellement difficile d’arriver à cet état de concentration.
Zach nous explique ensuite qu’il n’y a aucun horaire et que chacun est libre de venir travailler quand il se sent le plus productif. En effet, l’activité de développement requiert de la créativité et vous ne pouvez pas forcer les gens à être créatif pile entre 9h et 17h.



Du point vu de l’organisation, il n’y a pas de managers ou de chef de projets. Les équipes sont seules responsables de leur produit. Seule une ligne directrice est donnée par les 4 fondateurs. Après, libre à chaque membre de l’équipe de proposer et de travailler sur une nouvelle fonctionnalité si elle est reconnue comme intéressante par les autres membres de l’équipe.


Cette organisation peu habituel n’est rendu possible que par quelques facteurs important :

  • GitHub est une startup auto-financé et profitable depuis le début.
  • GitHub utilise GitHub. “eat your own dog food !”
  • GitHub est une société qui vend un produit.

Côté technique, là aussi c’est très intéressant. Du Ruby on Rails dans le cloud avec RackSpace. Ici encore, le mot d’ordre est de livrer la fonctionnalité le plus rapidement pour avoir le feedback le plus tôt possible. GitHub est redéployé entre 5 et 30 fois par jours !

Plusieurs techniques pour faire du continuous deployement sont utilisées.

  • feature branching.
  • Évidemment, comme on pouvait s’y attendre avec une entreprise reposant sur Git, les branches sont à l’honneur. Chaque nouvelle fonctionnalité fait l’objet d’une nouvelle branche. Mais attention, ne confondez pas avec les branches svn classiques que vous connaissez. L’idée ici est d’avoir une branche dont la durée de vie est très courte uniquement pour une feature qui doit rester simple. Les push (commits) sur la branche permettent d’avoir des codes reviews rapidement via l’interface GitHub.

  • super fast tests !
  • L’allié incontournable du continuous deployement, ce sont bien sûr les tests automatisés. Avec 8000 tests en 4 minutes, GitHub réduit très fortement les risques de régression à chaque redéploiement. Pour garantir dans le temps ce niveau de qualité et de réactivité un test lent est lui-même considéré comme une régression.

    Avec des déploiements aussi fréquent, il est nécessaire d’avoir du monitoring de qualité pour remonter au plus tôt les alertes. Les métriques donnent une perspective différente aux performances et permettent de cibler les points de contentions. Zach en profite pour nous montrer les métriques sur les clés ssh rejetées suite à la récente découverte d’une faille de sécurité majeure impactant tous les utilisateurs du site.

    Derrière le site Github, nouveau bastion des projets open source, se cache donc aussi une startup atypique. Elle rappelle fortement une autre société qui propose une organisation similaire : 37Signals, les créateurs du framework ruby on rails. Rien d’étonnant donc à trouver un post du CTO de Github expliquant comment ils ont suivi les judicieux conseils du livre de 37 signals, getting real, pour démarrer leur business.


    Ressources :

    GitHub
    How GitHub Works

    – Zach a écrit après la conférence sur sa façon d’écrire les slides. Je vous le recommande, car la forme était aussi bonne que le fond : Slides for developers

Categories: Divers Tags: , ,
  1. Pas encore de commentaire
  1. Pas encore de trackbacks