K33G_ORG's Blog

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:

Open IOT Challenge 3ème édition

L’an dernier, j’ai participé à l’Open IOT Challenge organisé par la fondation Eclipse et @kartben (aka Benjamin Cabé). C’est un challenge très sympa, où vous proposez seul ou en équipe un projet lié au domaine de l’IOT. Pendant plusieurs semaines vous devez publier vos avancées (tweets, blogs, …). La deadline pour s’inscrire est le 25 novembre, et les festivités durent jusqu’em février. Si votre projet fait partie des 10 plus intéressants, en décembre vous serez sélectionnés pour obtenir un “kit hardware” pour vous aider dans votre projet. Le 27 février, vous devez avoir fini et les gagnants sont annoncés en mars. Il y a de nombreux lots (20,000$) A savoir, l’an dernier j’ai eu le 3ème prix en proposant un projet uniquement “software” sur un DSL lié à la simulation et au stress de Gateway (MQTT, CoAP, http) en Groovy. Il est donc possible de “faire de l’IOT” de différentes manières. (mon humble création: http://k33g.github.io/2016/02/29/IOT-CHALLENGE-07.html)

L’intérêt de ce challenge est de travailler sur des cas d’usage concrets et donc d’avoir un vrai obectif. Donc si vous avez une idée en tête et une technologie à essayer/apprendre, c’est un très bon moyen d’apprendre et d’en sortir quelaue chose d’utile.

Ce qui me fait penser aue j’ai appris tellement de chose depuis 1 an, qu’il va falloir que je ré-écrive complètement mon projet de DSL (c’est mon challenge perso).

Donc, inscrivez vous, tout est possible, et c’est fun et instructif ;) https://iot.eclipse.org/open-iot-challenge/

WIP

(uk/us) I don’t blog anymore, I git push