Pourquoi GIT n’est pas magique ?

Certaines personnes pensent que GIT est “magique”. Il permet de merger mieux que SVN c’est donc l’occasion de faire plein de fork ? GIT permet de décentraliser, est-ce une bonne idée de le garder centraliser ? Autant de bonnes questions auquel il est important de répondre.

Comment savoir si vous utilisez mal git ?

• Vous avez plus de 20 branches en cours de développement sur votre serveur GIT
• Votre serveur GIT est centralisé et tout le monde utilise ce même serveur
• Tout le monde a le droit de push
• Aucune personne n’est en charge des merges
• Vous n’avez pas l’habitude de signer.

Si vous vous reconnaissez dans un ou plusieurs de ces choix, il faut revoir votre politique de développement .

TROP de fork TUE le fork.

GIT n’est pas magique et même si il facilite les merges entre les branches il n’est pas “conflict proof”. Certains conflits vont apparaitre c’est obligatoire, et ce n’est pas parce qu’il facilite les merge qu’il faut pour autant ne pas prendre des mesures pour les éviter.

Lorsque l’on décide de développer plusieurs projets en parallèles sur une même base il est bon de définir ce qui va être développé. Il est toujours bon dans une structure d’avoir une personne qui décide des points clés d’un projet et si plusieurs points se rejoignent il faut faire en sorte que les équipes n’effectuent pas le même travail chacun de leur coté ou alors vous risquez irrémédiablement d’avoir des conflits.

Cela peut paraitre “trivial” mais pour autant dans des structures de taille moyenne, il n’y a pas toujours de personnes dédiés à ce genre de coordination. GIT nous oblige ici à avoir un développement discipliné.

Une organisation bien défini

Si vous n’avez qu’un seul serveur GIT pour tout centraliser vous avez fait une grosse erreur. Pourquoi ?

• Si vous avez une équipe ou une personne avec des compétences assez médiocres, comment contrôlerez vous l’intégration de son développement ?
• Quand bien même vous auriez une équipe très compétente, quel est l’intérêt d’avoir tout vos commits centralisé sur un même serveur en permanence ? A part avoir beaucoup trop de branches et beaucoup trop de choses à gérer cela n’est pas très utile. C’est une mauvaise habitude résultant de l’utilisation de SVN

Intéressons nous à  l’organisation du noyau Linux. Si je devais la résumer en une seule phrase de Machiavel “Diviser pour mieux régner”. Si Linus Torvalds a choisit cette organisation ce n’est pas pour rien. C’est un geek et tout bon geek est fainéant.

Il fait confiance à un certains nombre de personnes. Il vérifie de manière ponctuel un certain nombre de patch mais si un patch qu’on lui envoie est signé par 2 ou 3 personnes de confiance il peut l’intégrer sans trop de vérification au noyau Linux.

Dans une entreprise cette attitude serait similaire a un coordinateur qui irait récupérer une branche git définit comme stable et qui ferait une vérification de cette branche avant son intégration. Si ce coordinateur n’a jamais eu de soucis avec le responsable du développement de la branche, il peut juste effectuer des vérifications sommaire mais là nous rentrons plus dans une relation de confiance et dans le relationnel entre les personnes de l’équipe.

Dans une grosse structure on pourrait voir ainsi 1, 2, 3, voir même 4 niveaux de hiérarchie entre le développeur et le “code keeper”. Le plus haut niveau n’a pas a se soucier des problèmes de développement, il a juste a valider la version finale qui sera intégrer dans le GIT. A contrario, le bas niveau n’a pas à se soucier de l’integration, il respecte juste un certain nombre de règles et développe son application.

Et si on pense que cela ne sert à rien ?

Si il n’y a aucune validation on peut se retrouver dans des cas dramatiques.

Un merge farfelus d’une branche en test dans un développement pour ne pas se prendre la tête et faire un raccourcis, des hotfix sur le noyau dans plusieurs branches, aucun suivis des branches upstream ou encore des merges avec une strategy “-s ours” sans vérification. L’intégration d’une branche “MAUDITE” peut devenir un vrai casse tête voir même impossible.

Au hasard les conséquences peuvent être:

• De nombreux conflits
• L’intégration de code “instable” par merge d’une branche déjà mergé avec une autre branche instable
• Rendre le code moins performant.

Bien sûr vous avez pu mettre un certain nombre d’indicateur comme des tests unitaires, des coverages reports mais il faut dans tout les cas avoir une organisation solide.

Cas pratique: la traversée du désert

Prenons un cas pratique que j’ai déjà eu l’occasion de voir. Ce cas j’aime l’appeler “la traversée du désert”.

Prenez un développeur, donnez lui une tâche et laissez le faire son fork. Il revient 3 mois après avec un développement qui a modifié votre noyau de base, qui n’a pas suivis les évolutions de l’upstream et qui soit dit en passant a sûrement réinventé la roue carrée. Résultat ? 3 mois de travail de perdu. Son code peut être considéré comme inutilisable.

L’image de traversée du désert montre bien l’image de ce développeur qui part seul sans radio avec une mission sommairement posé sur un bout de papier. Son chef de projet confiant pense que GIT arrivera comme un grand a merger ce qu’il “dénichera”. Il se trompe, cela ne changera rien.

Si vous deviez retenir que quelques regles ?

With great power comes great responsibility

1. Définissez une organisation.
2. Formez les personnes responsables aux différents enjeux.
3. Instaurez un climat de confiance entre les différents niveaux de votre pyramide.
4. Ne donnez pas des “pouvoirs” à des gens qui ne les maitrisent pas.
5. Définissez des règles pour les modifications de parties communes a tout les projets.

Ces règles pourraient être tout aussi utile pour un développement sous SVN mais le fait de faire des “fork” accentuent ces problèmes car les développeurs peuvent vite être isolé et leurs erreurs peuvent être detecté moins vite et avoir un plus gros impact sur le long terme.

Pour conclure

GIT est un outil puissant avec une grande liberté d’action. Il peut vous apportez beaucoup mais il faut bien comprendre son fonctionnement. Autant pour l’utilisateur néophyte qui fait un fork de Ruby on Rails pour rajouter une fonction, son utilisation est simple; autant pour la gestion de très gros projet, son utilisation peut être contre productive si vous n’avez pas une organisation bien structurée.

Si vous prenez la décision de changer de logiciel de versionning est d’adopter une méthode plus agile, plus souple, retenez bien cela ne se traduit pas que dans les logiciels que vous utilisez mais aussi dans l’utilisation que vous en faite.

Les mentalités sont encore habitués a un système de versioning centralisé avec un impact direct sur le développement. Avec GIT vous entrez dans des méthodes de développement sur le long terme où il faut savoir anticiper les problèmes avant de les laisser germer.

VITE URGENT ! Notre client “xxx” veut à tout pris une integration avec gloubiboulga maintenant. Cela ne PEUT pas attendre.

Cas de figure avec SVN

Je pense que vous avez déjà tous eu le cas d’un client qui a une demande super urgente.

La gestion de ce genre de cas est très difficile car:

1. L’application doit rester stable.
2. Les developpeurs ne DOIVENT pas gérer plusieurs version à la fois.

Concrètement cela va se résumer à la création d’une branche, sûrement un “branches/gloubiboulga”. Mais voila ! Il doit partir en production mais il n’a pas été testé dans tout les cas car le client sur lequel l’appli va être testé n’utilise pas toutes les fonctionnalités de votre logiciel et dans l’état, IL MARCHE. Il peut partir en production mais en aucun cas ne peut être mergé avec le “trunk”car cela pourrait causer un désastre sur le reste de l’appli. 3 versions se succedent et votre client revient en vous demandant “pourquoi ma version n’évolue plus ?”.

SVN donne de mauvaises habitudes

Si vous êtes un utilisateur de SVN vous devez trouver la gestion de branch assez “utopique”. On a souvent en tête le développeur un peu foufou qui part s’exiler 3 semaines dans un chalet pour faire un fork complet qu’il faudra reintegrer à l’appli. Le reste du temps, tout le monde développe dans “trunk” et trouve cela parfaitement normal. Pour reprendre une phrase que j’ai déjà souvent entendu “ça marche, pourquoi changer ?”.

Et si maintenant je veux une version stable, dans la seconde, je fais comment ?

Le soucis est maintenant, avec cette méthode de développement, si je veux une version stable instantanément je fais comment ? Vous allez me ressortir une vieille version stabilisé il y a 2 mois. Vous êtes sûr qu’elle marche, elle a était testé par 30 personnes de manières intensives pendant 2 semaines. Pourtant à l’heure actuel, vous pourriez peut être faire une version stable sauf que “Roger” doit finaliser un support de fichier quelconque et le soucis c’est que lui aussi travaille dans “trunk”.

Pourquoi on a prit de mauvaises habitudes ?

Tout simplement parce que SVN ne permet pas de faire simplement un merge dans les deux sens.

Si chacun travaille dans une branche dans SVN

1. Les merges peuvent devenir un cauchemard
2. Si Roger commit une amélioration, Patrick n’en beneficiera pas dans sa branche sans faire un merge qui pourrait devenir un casse tête.

Alors je vais vous poser deux questions:

1. Et si “trunk” devenait stable ?
2. Et si tout le monde crée une branche par amélioration à apporter ?

Maintenant on change la méthode de travail

Voici à présent comment sous GIT le développement peut s’articuler. Une branche est crée pour chaque “tache”. Les taches mineures pouvant bien évidemment être dans une même branche.

Il y a 3 principal zones

1. Les branches (en developpement)
2. La branche “Testing”
3. La branche “Stable”

On garantit ici la stabilité par 2 tests.

Le deuxième test est justifié sur de possibles interactions entre taches qui pourraient faire apparaitre des bugs qui ne seraient pas apparu pendant le test du module a la fin de la période de développement.

On se retrouve ici avec une architecture de développement proche des packages debian avec plusieurs niveaux de “stabilité”.

GIT serait-il magique ?

GIT permet une approche de développement totalement différente et permet plus facilement a mon sens de “stabiliser” une version d’une application si on utilise ce type d’architecture. Cependant il y plusieurs autre élément a prendre en compte.

• Une architecture de ce type est inutile pour des petits projects avec juste 2 ou 3 personnes
• GIT est un outil qui propose une grande liberté. Un merge avec par exemple “-s ours” pourrait causer des catastrophes desastreuses, il faut donc avoir conscience de ce que l’on fait.

Pour plus d’info sur git je vous conseille de voir comment fonctionne la fonction “rebase” de GIT et de consulter mais bookmarks associé sur “del.icio.us”
C’est mon premier post “serieux” sur mon blog… donc n’hesitez pas a donner des critiques .