Organisation des Codes Sources du projet CiviKey

Nous avons vu dans un post précédant que le serveur SVN pour CiviKey était accessible via l’url http://svn.invenietis.com/svn/CK et que le serveur d’intégration continue était accessible à l’URL http://ci.civikey.invenietis.com/.

Dans ce post nous allons voir la gestion du repository SVN ainsi que de Cruise Control .NET pour le projet CiviKey. Ce qui est présenté ici n'est mis en place que pour la version 2.5 de CiviKey (celle sur laquelle nous concentrons actuellement nos efforts).

Le repository SVN

Le noyau de CiviKey est divisé en deux: le Core, qui contient le noyau proprement dit et Certified qui contient les plugins certifiés. L’architecture globale est la suivante :

Structure des fichiers de CiviKey

/CK Root du repository Svn de CiviKey
/CK/Core Projet CK.Core
/CK/Core/trunk Trunk des développements du projet CK.Core
/CK/Core/releases Dossier des releases de CK.Core (cf. ci-dessous)
/CK/Certified Projet CK.Certified
/CK/Certified/trunk Trunk des développements du projet CK.Certified
/CK/Certified/releases    Dossier des releases de CK.Certified
/CK/Document/trunk Ensemble des documents

Organisation des Versions

Les "releases" sont gérées à de la façon suivante. Le projet DEMO (qui est un projet similaire à Core) détaille l'organisation de l'arborescence des releases :

/trunk Trunk principale du Produit.
/releases Dossier contenant l’ensemble des versions du Produit.
/releases/VER Une des versions du Produit.
/releases/VER/trunk Trunk de développement permettant de corriger cette version.
/releases/VER/tags Dossier contenant l’ensemble des tags pour cette version du Produit.
/releases/VER/tags/TAGS Un tag contenant les sources a un certain stade.

Ce système nous permet de gérer au mieux la montée en version du projet tout en préservant la liberté du développeur. Et il y tient le développeur à sa liberté.

Une petite histoire

Les développeurs travaillent dans /trunk qui est l’espace de développement principal.
Ils font des évolutions, des changements dans l’API pour mettre en place les nouveautés, et, un jour une version est prête à voir le jour, les développeurs décident donc de créer une Version, disons la 2.5.0.

Un nouveau dossier est créé dans /releases : /releases/2.5.0/trunk. Une Version est née, elle n'est pas parfaite (elle va avoir besoin de quelques retouches pour être finalisée) et va donc évoluer et donner naissance à des Tags.

Le premier de ces tags s'appelle CTP (pour Community Technology Preview, il aurait pu s'appeler Alpha ou PreAlpha ou autre nom qui indique que ce n'est pas vraiment sec) : /releases/2.5.0/tags/CTP apparait dans l'arborescence. Noter que les codes sources dans /tags n'évoluent pas: ils représentent des clichés, des instantannés, du /releases/2.5.0/trunk qui leur a donné naissance. Le trunk bouge, les tags figent.

Cet espace permet aux développeurs de continuer à travailler dans /trunk et donc de continuer à faire évoluer le noyau, pendant que d’autres travaillent pour la Version /releases/2.5.0/trunk afin de régler les derniers bugs qui pourraient exister. Une fois les derniers bugs corrigés dans le /trunk les développeurs créent le tag /releases/2.5.0/tags/Final (et espèrent très fort éviter le petit frère /releases/2.5.0/tags/SP1).(Voir http://en.wikipedia.org/wiki/Software_release_life_cycle pour des exemples de noms de révision.)

Pendant ce temps les développeurs du /trunk se sont lancés dans la future version 2.5.1 et ont d'ores et déjà produit une release en Alpha ce qui signifie qu’un dossier /releases/2.5.1/trunk a été créé ainsi qu’un tag /releases/2.5.1/tags/Alpha.

Cette petite histoire nous amène au dépôt suivant :

Avec ce système la version d’un projet à une vraie existence : les corrections sont possibles sans (trop) d'interférences ce qui libère le développeur, qui sait clairement s’il peut imaginer de nouveaux bugs (/trunk) ou s’il doit réfréner sa créativité (/releases).

Ajouter un commentaire

  Country flag

biuquote
  • Commentaire
  • Prévisualiser
Loading