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 .