GitHub Flow

Work in progress :construction:

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 :octocat: 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 :exclamation: Easy :stuck_out_tongue_winking_eye:

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 :woman: (or 1 :man:)

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

Mon job chez GitHub

C’est en général autour du :octocat: 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 :hankey: 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” :trollface:)

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 :wink:

blog comments powered by Disqus

Related posts