Le workflow chez github et des pistes pour votre entreprise

Le jeudi 29 septembre le lavajug (Java User Group de Clermont-Ferrand) organisait une conférence présentée par Alain Hélaïli qui travaille chez GitHub.

La présentation concernait les méthodes de travail dans l’entreprise et le process de déploiement d’une nouvelle fonctionnalité sur github.com.

Si vous souhaitez voir la conférence :

Git vs Github

Git est un outil de versionnage comme CVS ou SVN, c'est un des plus jeune, mais maintenant un des plus utilisés.

Github est une entreprise commerciale qui édite le site github.com qui héberge des dépôts git, et qui facilite la collaboration au sein d'une équipe projet avec différents outils, entre autres :

  • Le bug tracker ou "Issue" qui permet de lister les bug, idées... d'un projet et n'importe qui peut ensuite donner son avis dessus.
  • Les pulls requests : C'est un ensemble de modification de code (commits) qui ajoute une nouvelle fonctionnalité ou corrigent un bug. Sur github tout le monde peut modifier un projet puis ouvrir une pull request afin de proposer ses changements. Peuvent s'en suivre ensuite une discussion, une revue de code et enfin l'intégration ou non des modifications dans le projet.

Github est aujourd'hui le 50e site le plus consulté du monde avec 40 millions de visiteurs uniques par mois, et il est utilisé par la majorité des des projets opensource.

Github propose des dépôts gratuitement sous la condition qu’ils soient public et que donc le code, la documentation... soit consultable par tous. Mais le site propose aussi des dépôts privés (cette fois payant) où seulement vous et votre équipe pouvez voir et interagir avec le projet.

Github n'est pas le seul sur ce segment, on peut citer par exemple gitlab, qui est opensource et qui lui peut-être installé dans n'importe quelle entreprise en privé.

L'entreprise github

Github est une entreprise de la Silicon Valley (San Francisco donc) mais emploie des gens au niveau de la planète entière : Amériques, Europe, Afrique, Asie, Océanie. Les salariés font donc les 3x8 mais selon leurs fuseaux horaires respectifs.

À part quelques réunions en visioconférence (environ une fois par semaine) ou des submits annuels, il n'y a donc très peu d'oral dans la société. Tout passe par l'écrit.

Markdown vs Email

Au niveau du flux d’information pour commencer, chez Github, personne ne s’envoie d’email. Pour les discussions, tout se fait directement sur github.com (évidement dans des dépots privés, ils ont un avantage, ils sont gratuits pour eux) C'est vrai pour les équipes techniques, mais aussi pour toutes les autres fonctions de l’entreprise : commerciale, comptabilité, juridique... Chaque service a son dépôt github, sur lequel ils stockent leurs documents dans des fichiers en markdown, suggèrent des modifications via des pull-request, échangent de l'information via le bug tracker...

Pas de document word "conditions-generale-2016-02-27-V2-OLD.doc.BAK" perdu au 17e niveau d'une arborescence d'un dossier réseau. Un document est unique mais toutes les modifications sont consignées, et peuvent être annulée (comme l'on fait pour du code classique sur github.com.)

Slack rules all the things

Depuis quelques années Github utilise slack pour la communication interne, avec un grand nombre de salons de discussion. Slack est vraiment intégré dans l'entreprise car il permet de récupérer/envoyer de l'information :

  • Intégration avec github.com : notification de pull-request, de modification d'un document... rien de surprenant là dedans.
  • Intégration avec leur outil de CRM, les commerciaux n'utilisent jamais directement leur outil de CRM (salesforce il me semble) mais interagissent avec lui uniquement via slack.
  • Mise en prod, déploiement de fonctionnalités...
  • Monitoring, interaction avec Nagios...

Pour cela l'entreprise a développé son "bot" qui est presque "Employee of the month" depuis qu'il existe : Hubot c'est lui qui s'interface entre slack et tous les autres outils de l'entreprise.

La transparence

Je l'ai dit plus haut, toutes les informations de l'entreprise sont dans des dépôts, y compris les informations financières, et ces dépôts tous ouverts à l'ensemble des salariés.

Idem sur slack, tout le monde peut voir les sysadmins en pleine crise lorsque le site rame pour une raison inexpliquée, c'est comme au zoo, vous pouvez même leur balancer des gifs animés entre deux graphiques de charge serveur pour les rendre fous. Qui n'a jamais rêvé de ça ?

La transparence au niveau du code aussi. Vu que les pull-requests, les discussions sur de nouvelles fonctionnalités, les code-reviews... sont publiques aussi, potentiellement tous les développeurs sont au courant de ce qui se fait sur le site, pourquoi ça été fait comme ça, et aussi n'importe qui peut suggérer une modification, ou poser une question sur une section de code particulière. Du coup pas de «ah, bein ça c'est Kevin qui l'a fait, il est en congé, faudra attendre lundi».

Même un nouvel employé peut se plonger dans l'ensemble des discussions sur les choix (au niveau du code, mais aussi sur n'importe quelle fonction de l'entreprise) antérieurs à son arrivée.

Pas de mail => pas de «J'étais pas dans la boucle»

Le process de développement

Le Github flow

AKA : github flow

Note : je ne vais pas détailler longuement, le flux, vous trouverez toutes les informations que vous souhaitez sur : https://guides.github.com/introduction/flow/

Chez Github le paradigme est le suivant :

Master est la branche principale, qui est validée et qui doit être déployable à n'importe quel moment. Mais master ne reflète pas forcément l'état de la production.

Dans les faits, voici les étapes en lien avec le graph plus haut :

  1. Création d'une branche qui contiendra la nouvelle fonctionnalité
  2. *commit commit commit*
  3. Ouverture d'une pull-request (demande d'intégration de sa modification sur la branche principale)
  4. Discussions, code-reviews avec d'autres employés...
  5. Mise en prod (et quand je dis mise en prod, c'est sur la prod de Github, donc github.com !), Validation de la modification
  6. Fusion de la branche dans master

Sur github.com en fait, les beta-testeurs c'est nous. Il est rare que la version en ligne soit celle correspondant à la branche master.

Évidement ils ont pleins environnement de tests sur lesquels ils peuvent déployer des choses. Tout ne se fait pas en prod directement !

Toutes ces phases de déploiement se font directement depuis Slack, toujours via Hubot, avec un système de gestion de queue.

Par exemple il existe la commande slack wcid pour «Where Can I Deploy» qui liste les différents environnements de tests et de prod en indiquant pour chaque si l’environnement est libre ou s'il est «locké» car un déploiement est déjà en cours.

Si un déploiement est en cours, on peut s'ajouter dans la file d'attente, et Hubot viendra nous faire signe (encore et toujours dans slack) quand ça sera notre tour.

Un déploiement se passe donc sans connexion ssh à un serveur, encore moins via ftp, c'est beau.

Tl;dr

Github utilise github.com pour développer le site github.com et pour faire fonctionner l'entreprise Github, c'est tellement meta que ça en devient beau.

J'étais déjà convaincu qu'un outil comme gitlab ou github devait être au centre du fonctionnement de l'entreprise, cela vient confirmer ma pensée :

  • Pas besoin d'email, pas de document qui peut être à 36 endroits différents dans 36 versions différentes et dans 36 formats incompatibles entre eux. Ça doit être étrange pour un commercial d'entendre qu'il n'utilisera plus word mais un simple éditeur de texte avec le Markdown pour mettre en page tous ses documents. Mais au final le relatif temps d'apprentissage doit vite être rentable en vue du temps gagné dans le futur.
  • Plus besoin d'assister à des réunions inutiles, même si elles existeront toujours, elles ne concerneront que les personnes directement impliquées dans le sujet, les absents et autres pourront consulter le CR, poser leurs questions et faire leurs remarques directement dans le dépôt.
  • N'importe quelle demande de support, d'aide, remarque sur le fonctionnement de l'entreprise... doit être discutée, quoi de mieux qu'un bug tracker pour ça ?
  • Je suis nouveau ou j'arrive en pompier sur un projet car le dev principal est absent ? j'ai toutes l'information dont je peux avoir besoin sans avoir besoin de ses mails.
  • Toute l'entreprise fonctionne de la même façon, on a plus une personne qui gère son debug via un google doc, une autre via un flux de mail...

Bref, merci au LavaJUG et à Alain Hélaïli pour cette superbe conférence !

 

Ajouter un commentaire

Ne sera pas publié
CAPTCHA
Désolé, pour ça, mais c'est le seul moyen pour éviter le spam...