#InsideDevsBrain le fonctionnement du « Feature branching »​

Léo, jeune « newbee » dans le monde du développement, vient de démarrer son stage dans une grosse boite de « geek ». Le week-end il rentre chez lui, dans sa famille, et est très fier de raconter son expérience à sa tante.

Je suis refait Tati, mon pc et les locaux sont archi lourds et je travaille en « feature branching ». Je suis déter a continuer à gagner mon lové dans cette boite !

Ok tati ! je ne peux rien pour toi concernant le vocabulaire 2020, mais je peux t’éclairer sur la technique.

Alors c’est quoi le « feature Branching » ?

Pour t’expliquer ça facilement il faut commencer par les basics.

1, Les basics

Un développeur travaille toujours sur une grosse base de code (« code base »). Nous parlons de milliers de fichiers et millions de lignes de codes.

Un développeur n’est souvent pas seul à travailler sur un projet. Tu as donc potentiellement beaucoup de développeurs sur la même base de code.

Avec autant de personnes sur une « code base » la difficulté intervient lors de la mise en production. Pour faire simple tout le monde travaille de son côté, modif la « code base »… et au moment de la mise en production (ou pré-production). Si 2 développeurs ont modifié le même fichier au même endroit, c’est la catastrophe (Bug, régression…).

Bref, la problématique est d’éviter les conflits et de savoir qui a fait quoi quand.

Pour résoudre ce problème il faut utiliser un logiciel qui permet de gérer des versions du « code base » (ce sont des VCS et les plus connus sont GIT ou SVN).

Les fonctions principales de ces outils sont :

• De conserver un historique de chaque modification de chaque fichier.
• Si deux personnes travaillent simultanément sur un même fichier, ils sont capables d’assembler (de fusionner) leurs modifications et d’éviter que le travail d’une de ces personnes ne soit écrasé.

Ces outils sont, par conséquent, indispensables pour suivre les évolutions de la « code base » et pour travailler à plusieurs.

2, Ok mais quel est le rapport avec le « feature banching » de Léo ??

Et bien le « feature branching » est une méthode d’organisation du travail avec GIT ou SVN.

Avec les VCS, les développeurs sont capables de créer des copies d’une partie du code (que l’on appelle des « branches » de code).

Ces « branches » embarquent une partie du « code base » et elles permettent de modifier le code sans impacter celui de la branche principale.

Chaque branche a son cycle de vie bien défini (vous trouverez ci-dessous une table avec les noms de branches et leur cycle de vie).

Ce qui est intéressant maintenant c’est comment les développeurs s’organisent avec ces branches. Vous trouverez ci-dessous une vue des interactions possibles avec ces branches.

Et bien ce que l’on appelle le « feature branching » c’est la partie verte.

Dans cet exemple le développeur a isolé le code lié à la fonctionnalité pour la développer « tranquillement » sans interactions avec le reste du code. L’objectif sera (qu’à un moment) cette « branche » arrive dans le code principal pour être mise en production.

Ah ba super, mais pourquoi tu nous parles de ça?

Et bien je vous parle de ça, car j’aimerais que vous compreniez mieux l’organisation des développeurs afin de travailler plus efficacement avec eux.

Lorsqu’un développeur travaille (en feature branching) il « s’isole » sur une fonctionnalité, afin de ne pas être impacté par les modifications qui ont lieu sur le reste du code. Il mélangera ensuite ces modifications avec la branche principale.

A la fin de l’histoire, la difficulté reste la même si 2 développeurs ont modifié le même fichier dans 2 branches différentes ils devront trouver une solution au conflit lorsque la seconde branche rejoindra la branche principale. Mais ce qui change c’est l’organisation, avant de rejoindre la branche principale il saura qu’il y a un conflit et sera en mesure de trouver une solution en évitant un bug ou une régression.

Ce qui est important de comprendre c’est que grâce à ce type de méthode de travail :

1, Vos développeurs ne sont pas (tous) des geeks dégénérés qui font ce qu’ils veulent, mais des ingénieurs qui travaillent sur une fonctionnalité métier. Il est donc PRIMORDIALE qu’ils comprennent sur quoi ils travaillent.

2, Plus longtemps une branche sera isolée plus la base de code aura évolué et plus la probabilité d’avoir un conflit sera forte. Donc aidez-les en leur faisant travailler des petites fonctionnalités par itérations plutôt que d’énormes projets très complexes.

Si cet article vous a plu, la prochaine fois je vous explique pourquoi essayer de mesurer un coup de mise en production peut être important dans votre organisation…

Et si tu as envie d’en connaitre davantage sur les méthodes agiles lis cet article.

Si cet article vous a plu, vous pouvez continuer avec, #InsideDevsBrain Mieux comprendre l’intégration continue