La gestion des versions et des sources d’une application est un domaine très important de la gestion de la configuration. Tous les livrables d’une application ce versionnent, le code source, comme les documents. Pour commencer, cet article est orienté vers la gestion des sources et les outils qui s’y attachent.

En tant que développeur nous sommes tous amené à gérer nos sources et nos versions d’application (enfin normalement). Là ou un outil comme Subversion semble mal adapté à un développeur seul (il faut monter un serveur etc…), Git apporte une solution rapide à la gestion de nos projets perso et avec la montée en force de GitHub nous utilisons maintenant tous ces plateformes pour partager nos sources. Mais que faire lorsque l’on travail vraiment de manière collaborative et que la gestion des versions et des sources est un enjeu à part entière ?  

Pourquoi gérer ses sources ?

Voilà une bonne question. Quand on est seul face à son code, la gestion des sources est un moyen de sauvegarder son travail et de pouvoir revenir en arrière. Des plateformes comme GitHub apportent en plus la possibilité de partager son travail avec le reste du monde. Cette utilisation est très utile mais ne couvre qu’une toute petite partie de la gestion de sources. Dans le cadre d’une équipe (donc 2 développeurs minimum) et surtout face à des contraintes client, la gestion de sources nous sauve la vie. L’outil retenu et surtout la méthodologie mise en oeuvre sont des facteurs cruciaux dans une bonne gestion des sources.  

Les outils

Il existe sur le marché plusieurs outils de gestion de source et le but de cet article n’est pas de trancher sur tel ou tel outil (il y a bien d’autres sites qui s’occupent des trolls). J’ai utilisé CVS, Subversion et Git, dans cet ordre et j’ai bien sûr des préférences mais plutôt basées sur les outils qui gravitent autour de ces systèmes. Alors je vais peut être enfoncer des portes ouvertes, mais l’important dans tous ces outils, c’est le développeur qui les utilise. Il est préférable d’utiliser de manière optimale SVN que de galérer avec GIT. Les fonctionnalités de bases sont toutes là dans un cas comme dans l’autre. Et comme les fonctionnalités de base représentent 90% de l’utilisation d’un outil de gestion de source… Ainsi, ce qui apporte énormément à GIT à mon sens, de sont des systèmes comme GitHub. Un outil simple et efficace qui permet de publier du code, de la documentation le tout intégré sur un site accessible de n’importe ou. Et pour SVN, les accros de l’explorateur et du menu contextuel sont extrêmement efficace avec TortoiseSVN.  

La méthodologie

Si comme je le pense l’outil n’a que peu d’importance il reste un facteur crucial, la méthodologie.

Le concepts des branches et des tags

Les tags sont des images figées de vos sources à un instant T. Par définition, les tags ne doivent donc pas changer car ils représentent une version précise de l’application. A chaque livraison de l’application doit correspondre un tag.   Les branches sont des versions qui évoluent par l’intermédiaire de corrections ou de nouveaux développements. Il y a donc deux catégories de branches :

• Les branches par produit  : branche évolutive
• Les branches par objectif : branche corrective

Donc les branches devraient être créées tout au long du projet, une branche par correction et évolution qui vie et meurt selon l’activité quelle représente.  

L’outillage

Etant donné que dans SVN la gestion des branches est lourde, on évite souvent d’utiliser de manière trop “intense” les branches. Dans Git c’est plutôt l’inverse, on cherchera à travailler en branches successives. Git semble donc plus adapté à un régime de production ou de multiples versions peuvent vivre en même temps. Et c’est donc paradoxal car à l’heure actuelle en entreprise SVN est l’outil le plus souvent utilisé alors que Git est privilégié en usage personnel. Si l’outil n’a que peu d’importance, il doit impérativement répondre à un besoin.   L’outil de gestion des versions est une chose, les outils gravitant autour ne sont pas à négliger. Ceux qui n’aiment pas les lignes de commandes vous le dirons et pourraient même choisir leur outil à cette seule condition… car un TortoiseSVN est beaucoup plus simple à prendre en main que de multiple lignes de commande. Dans le même esprit, les plugins de vos IDE préférés joueront un rôle important dans le choix de votre outil. Mais certains outils de gestion de source offre des atouts remarques, comme GitHub (ou GitLab dans les milieux plus “privés”). Ces portails offres de multiples fonctionnalités qui simplifient la gestion des sources au quotidien. Le “merge request” par exemple, illustre parfaitement ce que doit être une revue de code au sein d’un projet de qualité. Le “pair” est guidé dans sa revue par un périmètre clair, la communication est simplifiée au maximum entre le “pair” et l’auteur du code.  

Illustration

Je vous propose pour illustrer tout cela de prendre un exemple classique.

• une version 1.0.0 est en production,
• une version 1.1.1 est en test (chez le client),
• une version 1.2 est en cours de développement.

Les anomalies détectées en version 1.0 sont a traiter en urgence (en général) car elles apparaissent en production. Les anomalies en version 1.1 sont à traiter rapidement car elles pénalisent les tests du client, alors que la version 1.2 est une version de développement qui n’est donc pas stabilisée.   Le cas de figure est le suivant. Un bug majeur est détecté en production, en même temps, les tests menés par le client ont remontés une anomalie qui empêche de continuer la recette, et enfin on prépare la livraison du sprint pour la fin de la semaine. Dans mon gestionnaire de source, j’ai donc :

• Un tag 1.0 correspondant à la version en production.
• Une branche 1.1 correspondant à la version en cours de tests.
• Une branche trunk ou master correspondant à la version en cours de développements.

L’équipe en charge des corrections sur la recette va missionner une personne pour la correction du bug de production. Ce sauveur va donc partir du tag 1.0 pour faire une branche corrective 1.0. Une fois la correction faite, un nouveau tag 1.0.1 sera créé à partir de sa branche puis livré au client pour recette.

La branche 1.0 va donc mourir dés la mise en production après avoir été mergée avec les branches 1.1 et “trunk/master”. Pendant ce temps le reste de l’équipe en charge des corrections continue à créer des branche “fixXXX” sur la branche 1.1 pour corriger les anomalies.

Chaque merge d’une branche “fixXXX” vers la branche “1.1” va passer par une revue de code (merge request). Ce procédé va éviter d’injecter des régressions dans le code en cours de stabilisation.

Ces mêmes branches “fixXXX” vont également être mergées vers la branche “trunk” ou “master” pour que la version en cours de développement bénéficie des correctifs.

Et enfin, l’équipe qui prépare le sprint va bénéficier des corrections de production et de recette sans pour autant être stoppée dans leurs développements. Chaque développement fait l’objet d’une branche “featureXXX” qui va passer par une revue de code (merge request).

Alors bien sur la méthodologie illustrée ici n’est pas la seule existante. Il faudra réfléchir à cette méthodologie afin de réponse à un besoin précis et surtout en adéquation avec l’outillage que vous souhaitez mettre en oeuvre. Bienvenue, dans la gestion de conf…