SVN pour des projets web

Publié le 2008-03-14

SVN est un outil de versionnage extrêmement puissant tout à fait adapté pour le Web. Cet article décrit son application spécifique à du développement Web.

Un des problèmes communs auxquel fait face toute équipe de programmeurs est le suivi des modifications et des mises à jour du projet dans un environnement où plusieurs acteurs intéragissent ensemble.

Les développements Web (sites Web ou applications web) ne dérogent certainement pas à cette situation. Un projet Web est de nature aussi complèxe que tout autre projet informatique. Parmis les acteurs agissant dans un projet Web, nous pouvons identifier (entre autres):

Le chef de projet: qui supervise le déroulement du projet durant tout son cycle de vie. Le chef de projet intéragit avec le client et participe à l'élaboration des spécifications du projet. Les documents de spécifications sont bien entendu mis à jour tout au long du projet.
Les graphistes: qui conçoivent le matériel graphique unique au projet.
Les programmeurs: qui s'occupent de créer le code du futur site ou de la future application. En règle générale, plusieurs programmeurs sont amenés à collaborer sur le même code.
Les édimestres: qui se chargent de la rédaction du contenu en collaboration avec les analystes en positionnement.
Le(s) traducteur(s)
Les analystes en positionnement: Qui analysent (besoins, concurrence), déterminent des objectifs et plans d'actions pour obtenir le meilleurs positionnement du site Internet sur les moteurs de recherche.

Étant donné le nombre d'intervenants sur un seul et même projet, il est primordial de pouvoir simplifier la collaboration entre les acteurs et de se garder un historique complet des évolutions du projet.

À ce titre, un outil collaboratif de versionnage est tout à fait adapté à cette fonction. Un outil de versionnage permet de garder un historique, tout au long du cycle de vie du projet, des différentes modifications du projet sur tous les types de documents (documents de spécifications, matériel graphique, codes sources, textes originaux, textes traduits, ...)

Plusieurs outils, divers et variés, existent sur le marché, chacun avec plus au moins de fonctionnalités utiles selon le type de projet. Parmis les outils Libres (Open Source), deux se distinguent par leur popularité: CVS et SVN. Ces dernières années, SVN a tendence à remplacer CVS considéré désuet compte tenu d'un certain manque en fonctionnalités. Nous nous concentreront donc dans ce billet sur SVN.

Principe de fonctionnement de SVN:

Comme la plupart des outils de versionnage, SVN fonctionne sur un modèle Client/Serveur:

Le serveur: Contient la dernière version du projet ainsi que toutes les modifications (qu'on appellera dorénavant des Révisions) qui sont intervenues depuis le lancement du projet. L'historique est conservé de manière incrémentielle: seuls les ajouts à un fichiers sont stockés. Le fichier ne sera donc pas re-stocké pour chaque révision.

Le client: Qui représente une copie "Locale" du projet à une révision donnée. Donc, chaque acteur du projet doit conserver cette copie locale sur son ordinateur ; cette copie locale représente la version de travail. Lorsque l'acteur du projet a terminé de travailler sur un document donné ou sur une fonctionnalité précise, il valide son travail au près du serveur (appelé un commit). Le serveur lui répond avec le nouveau numéro de révision du projet.

Nous pourrions écrire un livre sur le mode de fonctionnement de SVN mais c'est au delà des objectifs de ce billet. D'ailleurs, un livre existe: le SVN RedBook.

Application de SVN aux projets Web

Dans le cadre d'un projet Web, différents types de fichiers entrent en ligne de compte:

Le matériel graphique
Le code HTML, CSS Javascript
Le code applicatif (PHP, ASP, .NET, ...)
Du matériel multimédia (Flash, vidéo, sons,...)
La documentation du projet (PDF, Word, Excel, ...)
Et bien d'autres selon les spécificités du projet.

Du point de vue de notre moteur de versionnage, il existe une distinction importante entre ces type de fichiers: certains sont des fichiers texte, d'autre ne le sont pas (ils sont donc binaires).

La principale différence entre des fichiers textes et binaires se situe dans la façon d'en stocker les différentes versions du même fichier. Un fichier texte est stocké sur une base incrémentale: seules les modifications sont stockées. Un fichier binaire, quand à lui, est stocké en entier à chacune des modifications. Certes celà engendre un problème de taille occupée par notre projet sur le serveur SVN: si un fichier binaire d'une taille moyenne de 10Mo est modifié 40 fois dans le cycle de vie du projet, celà occupera un espace disque de 400Mo sur le serveur pour ce seul et unique fichier. Celà dit, et compte tenu des prix au Mo des disques durs qui sont en constante baisse, nous pouvons nous permettre d'ignorer ce problème.

L'atout majeur des fichiers textes n'est, en effet, pas le peu d'espace occupé par les différentes révision des fichiers mais plutôt la possibilité d'analyser les différences entre les différentes révision. Admettons, par exemple, que nous devons apporter des modifications à une classe qui s'occupe de calculer les frais de port d'un site Web de commerce électronique. Si après diverses modifications (plusieures révisions) de la classe, on constate une régression dont nous ne nous sommes pas rendus compte, un comportement (non SVN) serait de revenir à la version de production et de trouver et ré-intégrer les différentes nouvelles fonctionnalités qu'on a implémenté depuis pour les ré-implémenter tout en tenant compte du bug qui s'est produit. Un comportement SVN serait de revenir à la dernière révision qui ne comportait pas cette regression et comparer les deux fichier. Des outils de "diff" existent pour une comparaison visuelle des versions. Cette fonction de comparaison entre les révision n'est pas possible pour les fichiers binaires.

Ceci nous amène donc à conclure que:

Les fichiers textes se doivent d'exploiter au maximum de cette fonctionnalité. Nous devons donc favoriser des commit "atomiques". En d'autres termes, nous devons valider notre version de travail à chaque implémentation d'une petite fonctionnalité sans forcément attendre l'intégralité de la mises à jour requise.
Les fichiers binaires devaient être validés dès que la mise à jour est finalisée. Par exemple, dans le cadre d'une maquette graphique, le fichier photoshop doit être validé (commit) dès que la modification globale a été effectuée et non après l'ajout d'un dégradé par exemple...

Structure de fichiers d'un projet Web sous SVN

Une des puissance de SVN étant sa souplesse. Il convient à tout type de projets et nous ne sommes pas limités au niveau de la structure des fichiers. Cette règle reste valable pour un projet Web et chacun adopte la structure de fichiers qui lui convient le mieux. Chez Cibaxion, nous adoptons la structure suivante (liste des dossiers):

/docs : contenant toute la documentation projet comme le cahier des charges, les cahier de spécifications et de conception, modèle de base de données...
/graph: contient le matériel de création graphique et multimédia du projet.
/sql: contient les scripts SQL du projet pour la mise en place de la base de données et son optimisation. C'est le dossier attitré à l'administrateur de base de données.
/trunk: contient la projet à proprement dit sur lequel travaillent les développeurs.
/tags: contient les différenyes branches du projet. Une branche est un copie identique du projet sur lequel on implémente des fonctionnalités tout en continuons de travailler sur la version de production du projet. C'est relativment utile lorsque nous devons ajouter une fonctionnalité non urgente et qui risque de comprommettre le fonctionnement de la version actuelle, tout en ajoutant d'autres fonctions urgentes sur la version actuelle. Le but de l'opération étant de jumeler, à terme, les deux versions.
/branches: pour travailler sur une autre version du projet tout en continuant de travailler sur la première.