GitHub Flow

Work in progress

Aujourd’hui j’ai envie de vous parler du GitHub Flow (https://guides.github.com/introduction/flow/), (je vous dirais plus loin pourquoi je vous en parle). Ce flow est le workflow utilisé chez parceque:

• Il est simple, voire ultra-simple
• Il est adapté à de l’intégration continue et du déploiement continu
• Il est facile à utiliser en équipe

Principes du GitHub Flow:

Les grands principes du GitHub Flow sont les suivants:

• Nous avons une branche master et tout ce qui est sur cette branche est déployable
• Si un membre de l’équipe doit faire une “feature” (fonctionnalité):
  • il crée une branche à partir de master
  • il commence à initialiser son code et fait quelques commits, puis les “pousse” vers le serveur, avant d’avoir terminé
  • et il propose ainsi une pull request (merge request pour ceux qui font du GitLab)
  • et par là même il initie une discussion autour de son code avec l’équipe
  • continue à commiter sur sa branche
  • chaque “push” vers le serveur déclenchera les traitements d’intégration continue (tests, qualimétrie, …)
  • etc…
• Une fois la fonctionnalité terminée et approuvée par tous, il peut merger sa branche sur master
• Et comme, tout ce qui est sur master est déployable, on déclenche le déploiement (automatiquement par exemple)

… Et c’est tout Easy

Et pour que cela fonctionne de la manière la plus simple possible (sans accroc):

• les petites “features” sont plus faciles à merger
• “poussez” souvent (synchronysez souvent aussi)
• si possible: 1 “feature” pour 1 (or 1 )

Et vous aurez un “flow” facile à utiliser, facile à apprendre (pensez aux petits juniors dont vous allez hériter sur vos projets) et facile à adapter

Mon job chez GitHub

C’est en général autour du flow, que j’articule mes démonstrations chez les prospects, clients, universités, … Mais présenter ça (un workflow d’équipe), quand vous êtes tout seul … Comment dire… C’est pour ceux qui regardent, mais pour moi aussi. En plus je parle d’intégration continue, de déploiement continu, mais aussi de ChatOps (le terme à la mode du moment, Eh oui, DevOps c’est déjà “has been” )

Du coup j’ai décidé de me faire aider pour faire mes démos par @babs, @buster et @bob pour avoir une “vraie” équipe:

• @bob sera le bot qui m’explique ce qu’il se passe sur mes repositories, et il fait ça dans RocketChat
• @babs et @buster sont des utilisateurs qui répondent à mes questions dans les discussions des issues ou des pull requests

Vous l’aurez deviné, @babs, @buster et @bob sont des bots. Je les ai développés à partir du framework Hubot (https://hubot.github.com/).

Ma démonstration utilise un “mini” serveur d’intégration continue que j’ai codé en JavaScript et les déploiements sont faits dans Docker.

Ma démo

Voici à quoi ressemble ma démo:

Mais avec une seule branche, je gère comment mes versions?

Tout simplement avec les tag releases. Et à partir d’un tag, vous pouvez “tirer” une nouvelle branche pour faire un fix:

Et pourquoi cet article alors?

En fait dans les semaines à venir, je vais vous expliquer:

• comment j’ai codé mon serveur de CI et de CD
• comment j’ai codé mes bots
• et j’aurais (j’espère) aussi un article sur comment coder sont propre DVCS (aka son propre GitHub mais en version mini)

Donc … Stay tuned