GIT, GitFlow et l’intégration continue pour les nuls
Ca ne fait de mal à personne de comprendre comment les développeurs travaillent…
This article is also available in English.
Une fois que les développeurs ont fini de “coder”, qu’arrive-t-il à leur code ? Comment font-ils pour retrouver leur code ? Je vais essayer de l’expliquer au travers de cet article, en réduisant au maximum l’utilisation de mots techniques.
En quoi ça me regarde ?
Si vous vous posez cette question, alors j’imagine que ça ne vous intéresse pas de simplement comprendre comment fonctionne votre équipe.
Pas de soucis, voici deux raisons supplémentaires pour lesquelles vous devriez vous y intéresser.
Tout d’abord, la raison la plus importante est probablement parce que cela vous permettra de briller en société. Et comme vous le savez certainement, c’est clairement le plus important !
Et ensuite, parce que la manière dont travaillent les développeurs impose directement des contraintes sur la capacité à livrer du fonctionnel. Comprendre l’envers du décor vous aidera à réaliser que ces développeurs ne sont pas juste des divas irresponsables qui essaient d’asseoir leur puissance dans la boîte. Non, il se trouve qu’en fait c’est réellement difficile et qu’ils font déjà leur maximum.
Le Monde du Développeur — Définitions
Nous allons passer en revue et expliquer les termes et noms suivants :
- Gestion de version
- GIT
- Branches
- Fusion (merge)
- Modèle de branches (branching model)
- GitFlow
- Intégration
- Intégration Continue
Gestion de version
Un développeur travaille. Il produit du code. Ce code est partagé et enregistré en sécurité dans un outil. Ce genre d’outil est appelé gestion de version non seulement parce qu’il stocke en sécurité le code et qu’il permet aux développeurs de partager leur code et de collaborer en équipe sur le même code, mais aussi parce qu’il versionne le code. Cela veut dire que lorsqu’un développeur ajoute du code, il ne remplace pas la version précédente mais ajoute à la place un changement dans l’historique. De cette manière, ce n’est pas grave lorsqu’un développeur fait une bêtise car il est très facile de revenir à la version précédente. Ils peuvent également regarder l’historique pour comprendre ce qu’il s’est passé dans le code lorsqu’il mènent l’investigation d’un problème.
Du manière ou d’une autre, vous avez déjà utilisé ce concept dans un des nombreux outils collaboratifs qui existent en dehors du monde des développeurs. Google Doc, Slides et Sheets ont ce concept d’historique : vous pouvez passer en revue les derniers changements et reprendre une version précédente. On peut en dire autant de Wikipedia et des autres logiciels de Wiki, qui comme les outils de développeur proposent d’ajouter un commentaire pour aider les autres utilisateurs à comprendre facilement l’historique. Il est d’ailleurs expressément demandé aux contributeurs de Wikipedia de prendre le temps d’écrire un tel commentaire pour aider à maîtriser les mauvaises éditions.
GIT
Et GIT, et bien, est un exemple de logiciel de gestion de version. Il y a de nombreux logiciels de gestion de version disponibles, mais la plupart des personnes sont d’accord pour dire que GIT est le meilleur dans cette catégorie pour plein de bonnes raisons. Aussi aujourd’hui la plupart des équipes utilisent GIT.
Branches
Comparer les solutions de gestion de version pour développeur avec Google Docs et Wikipedia a certaines limites. Quand vous utilisez des outils à destination du grand-public, il n’y a qu’une et une seule vérité à tout moment. Il y a tout un historique qui explique comment on est arrivé à cette vérité, mais quoi qu’il arrive il n’y a toujours qu’une et une seule version courante. Et quelque soit la modification que vous faites au document, c’est toujours sur cette dernière version, la version courante.
Le travail des développeurs peut être nettement plus complexe que ce que vous pouvez faire dans Google Docs ou dans Wikipedia. Voici quelques exemples :
- Plusieurs versions du logiciel sont simultanément en production
- Des correctifs doivent être livrés sur une version précédente
- De grosses fonctionnalités prennent beaucoup de temps à développer et ne peuvent pas être directement ajoutées à la dernière version, la version courante
- Valider une nouvelle version du logiciel prend du temps, aussi les nouveaux développements faits durant cette phase de test ne peuvent pas encore être ajoutés à la version en production
- Et ainsi de suite…
Toutes ces situations correspondent à l’utilisation de ce qu’on appelle des branches dans la terminologie du gestion de version. Une des branches a un sens spécial et représente ce qui est en production, ce qui est la dernière version, la version courante. Dans GIT, cette branche est généralement (mais pas toujours) appelée la branche master.
Quand les développeurs créent une nouvelle fonctionnalité, ils ne travaillent pas directement sur cette branche; ils créent une nouvelle branche qui part de cette branche d’origine et ils peuvent ainsi travailler librement et indépendamment de la branche d’origine. Une fois que le travail est terminé, la branche est fusionnée (merge) à nouveau avec la branche principale.
Il en va de même pour les autres exemples que j’ai donné. Corriger un bug sur une version précédente du logiciel… Oui, ce sont des branches. Avoir des fonctionnalités en validation avant d’aller en production… Oui, d’autres branches.
Créer et fusionner des branches fait littéralement partie de la routine du développeur. C’est tout simplement comme cela qu’il fait son travail.
Fusion (merge)
J’ai introduit le terme fusion dans la section précédente. Justement, c’est la partie épineuse de l’histoire 😅
Fusionner des branches n’est pas toujours facile; entre deux versions, laquelle est la bonne ? Il n’y a pas de réponse évidente, et souvent il faudra prendre les changements des deux branches. Et parfois même les changements d’une branche impactent du code qui existe uniquement sur l’autre branche : lorsque la branche ajoute du code qui utilise du vieux code qui a été modifié dans l’autre branche. Non vraiment, réussir à fusionner des branches n’est pas toujours trivial.
Point intéressant, une des raisons pour lesquelles les gens disent que GIT est si bien, est précisément parce qu’il rend le travail de fusion plus facile.
Modèle de Branches (branching model)
Fusionner peut donc être délicat. Cependant le type de fusions que rencontrera l’équipe dépend de quand les branches sont crées et de comment elles sont gérées. Aussi l’équipe se met en général d’accord pour suivre certaines règles sur la création et la fusion de branches : ces règles sont appelées un modèle de branches.
GitFlow
GitFlow est un exemple de modèle de branches. Il sort du lot parce qu’il est largement utilisé et que la communauté l’a largement documenté. GitFlow est également populaire parce qu’il est très facile à comprendre pour les nouveaux utilisateurs de GIT : pour l’essentiel GitFlow reprend le mode de fonctionnement qu’on retrouve dans la plupart des logiciels de gestion de version.
Aujourd’hui, je pense que le plus grand avantage de GitFlow est d’être largement répandu : c’est une manière de standardiser les pratiques de gestion de version entre les différentes équipes et sociétés, et d’accélérer la mise à niveau des nouveaux développeurs.
L’équipe utilise GitFlow, un nouveau membre est recruté, il connait GitFlow, il peut contribuer au projet dès son premier jour dans l’entreprise.
Pour résumer GitFlow:
- master représente ce qu’il y a en production
- Le travail sur les fonctionnalités et les correctifs sont effectuées dans leur propre branche
- Les branches de fonctionnalité ou de correctif ne sont pas fusionnés directement dans master lorsque le travail est terminé ; elles sont fusionnés dans une branche nommée develop
- develop est ainsi un tampon entre “développement terminé” et “en production” ; les branches de release sont crées à partir de develop puis fusionnées dans master
- Les branches de release peuvent ainsi être testées et validées pendant tout le temps nécessaire en environnement de pré-production
Intégration
Comme je l’ai expliqué plus haut, la fusion de branches peut être assez délicat. Il est dur de prédire les interactions entre différents morceaux de code.
Sans surprise, les développeurs résolvent le problème en testant le logiciel résultant de la fusion. Si rien n’est cassé, on est bons !
Tout ce processus est appelé intégration : on intègre ensemble deux versions du logiciel en fusionnant leurs codes et en vérifiant (testant) que tout fonctionne comme prévu.
Intégration Continue
De toute évidence, tester le logiciel à la main prend beaucoup de temps, est sujet à l’erreur humaine (sans même parler de l’ennui humain 😒), et globalement cela ralentit tout le processus de développement.
Entre alors en scène l’idée d’intégration continue, où les tests sont automatisés et exécutés par un autre logiciel. Le logiciel d’intégration continue le plus connu est peut-être bien Jenkins (encore un terme à caser en soirée avec votre équipe de développement !).
Le modèle de branches GitFlow fonctionne très bien avec l’intégration continue. L’idée de base est de s’assurer qu’à chaque fois qu’une branche de fonctionnalité est fusionnée dans develop, l’intégration continue vérifie que tout est bon sur cette branche principale. Cette vérification est effectuée régulièrement. En fonction du contexte du projet et de la maturité de l’équipe, cette vérification peut n’être effectuée qu’une seule fois par jour, ou au contraire à chaque fois qu’un développeur effectue le moindre changement 😵
(conseil : plus le feedback est rapide, mieux c’est)
Que retenir ?
Mettre en place les bonnes pratiques de gestion de version, de modèle de branches et d’intégration continue n’est pas facile mais pourtant crucial.
Les développeurs doivent passer beaucoup de temps sur ces sujets. Ils devraient s’accorder sur les manières de faire et suivre les mêmes règles, en équipe. Ils devraient régulièrement remettre en question leurs pratiques et en chercher des meilleures. Ils devraient mettre en place ou créer tous les outils dont ils ont besoin pour bien faire leur travail.
Et quand c’est le cas, on obtient en retour un meilleur time to market ! 🤑