Lors du premier DevFest de Lille, notre Sfeirien Emmanuel a pu interviewer Alain Helaili à propos de GitHub Flow. Vous ne savez pas ce que c’est ? Suivez le guide !
Bonjour Alain, peux-tu te présenter ?
Bonjour, je suis Alain Helaili, je suis Solutions Engineer chez GitHub. J’aide les clients qui veulent déployer GitHub Enterprise à définir l’architecture cible, mais aussi à repenser leur manière de travailler avec Git et GitHub. Je travaille également avec la communauté des utilisateurs de GitHub.
Suite à ton talk, ton workflow m’intéresse beaucoup, mais comment convaincre d’autres utilisateurs ?
(NDLR : présentation du workflow GitHub ici)
Il faut aborder le problème par l’angle de l’objectif final. Expliquer à un utilisateur métier qu’on veut pouvoir passer d’une idée à une mise en production en un minimum de temps. Partant de cette volonté, l’idée est de se mettre en ordre de bataille pour pouvoir arriver à cet objectif avec un chemin sécurisé au maximum.
Quels sont les risques de mise en production ?
La mise en production en elle-même ! L’idéal c’est de complètement automatiser le processus et de faire en sorte qu’il fonctionne pour un déploiement sous n’importe quel environnement. L’idée est d’avoir exactement les mêmes étapes, le même code pour passer d’un environnement de QA, à celui de test et enfin de production. À partir du moment où l’on sait que notre processus est 100% fiable et répétable, les dangers de la mise en production sont quasi éliminés.
De toute façon, ils seront toujours moins importants quand on a
l’habitude de le faire très fréquemment plutôt que quand on le fait une fois par mois. Plus on le fait, plus c’est sécurisé.
Tous ces frameworks (Gh-ost, Flipper et Scientist) que tu présentes nécessitent de modifier le code de production. N’y a-t-il pas un risque en ajoutant ou enlevant ce code de casser quelque chose ?
Ça ne fait qu’un framework de plus parmi les 250 qu’on utilise déjà, ce n’est pas un gros risque. Il faut évidemment les maitriser un minimum et ça va rajouter sans doute un petit peu de travail de maintenance. Mais rien de très grave.
Quand on parle de Scientist ou de Flipper, il faut penser à supprimer les expérimentations qui n’ont plus lieu d’être, les features flags inutiles, etc. Ce ménage est important, mais ça touche du code qui est assez trivial. Il n’y pas de gros risques.
Qu’est ce que tu conseilles comme bonnes pratiques pour mettre tout cela en place au-delà des frameworks ?
Il faut que les équipes soient responsabilisées. Je pense que le problème côté technique n’est pas très compliqué : tout existe, tout est là, il suffit de le mettre en place. La mise en production automatisée, on sait le faire, il y a plein de techniques qui existent maintenant depuis des années qui nous permettent de gérer ça simplement.
Pour moi, le critère clé c’est la responsabilisation des développeurs, qu’ils aient conscience qu’il est important pour eux de suivre une fonctionnalité jusqu’à la production. À ce stade, c’est aussi à eux de regarder ce qui se passe, donc il faut leur donner les outils pour avoir l’information. Si on ne fait pas ça, on ne va pas les responsabiliser. Il est impératif qu’ils puissent observer l’impact de leur code en production, de manière autonome et sécurisée.
Pour avoir tout ça, il faut passer du temps sur l’outillage de l’intégration continue, rappeler à tous qu’il est important de donner le maximum de feeback possible aux développeurs et de continuer à le faire jusqu’à la production.
Du reste, pour moi CI ce n’est plus Continuous Integration mais Continous Information ! Il faut qu’ils aient de l’information en permanence pour pouvoir prendre de bonnes décisions et détecter rapidement que quelque chose dévie par rapport à la cible de qualité.
Une dernière question qui me trotte dans la tête par rapport au workflow avec Git : pour ou contre le squash avant le merge de la branche ?
Chez GitHub, on ne s’en préoccupe pas pour une raison très simple : historiquement les équipes regardaient le gitlog pour savoir ce qui s’était passé, mais nous, on ne regarde pas ça, on vérifie les pull requests. Donc que ce soit un squash, un rebase, un merge, un fast-forward, etc. la pull request est identique et c’est ça qui compte.
Merci Alain.
The post Interview : Alain Helaili présente Github Flow appeared first on SFEIR Mag.