La clé est d’organiser le projet de façon modulaire en évaluant correctement les différentes briques fonctionnelles et techniques du projet à mettre en place.

Nous prendrons dans notre exemple le cas d’un projet développé sous Eclipse et dont le serveur d’application cible est Tomcat. Tout autre technologie est bien sûr envisageable.

Le découpage des sources
Tout d’abord il conviendra d’effectuer un découpage fonctionnel des différents modules ou accès de l’application. Nous pouvons prendre le cas d’un projet proposant un Back Office et un Front Office. Chaque module fonctionnel sera déclaré comme un projet à part entière et consommera des fonctionnalités, méthodes et outils communs présents dans un autre projet contenant le framework maison ou tronc commun. Outre une maintenabilité accrue pour l’ensemble du projet par la suite, cela permet de séparer clairement les éléments nécessaires à la compilation et exécution de chaque modules qui pourront s’exécuter sur des environnements/serveurs distincts. En effet, sur un site commerçant par exemple, le Back Office nécessitera probablement une infrastructure minimale afin de remplir les produits qui seront accessibles au grand public sur le Front Office qui pourra nécessiter une infrastructure plus poussée afin de supporter la charge, avec un système de réplication de données master-slave par exemple. Il faut donc que chaque module soit indépendant afin de pouvoir être déployés séparément sur des infrastructures distinctes.

L’intérêt d’avoir un projet à part pour le tronc commun permet en plus d’effectuer des montées de versions rapides pour peu que les méthodes et interfaces dudit framework maison aient été convenablement définies et ne bougent pas ou bien que la rétrocompatibilité soit assurée de manière générale. Cela permet d’avoir une version ISO du framework entre les différents projets (pas au sens Eclipse du terme mais au sens « business ») de la société et que chacun puisse profiter des dernières corrections et évolutions du framework maison.

Concernant les framework du marché, la séparation n’est pas aussi simple puisque, plus qu’un ensemble de méthodes et d’outils, ils proposent des modèles de développement, et donc qu’en général, les sources sont intégrées directement dans leur modèle, comme dans Struts pour ne citer que lui. Il n’est donc pas nécessaire de vouloir extraire dans des projets séparés tous les framework, car cela ne serait pas forcément bénéfique.

Le cas des outils éditeurs
Reste en suite le cas des outils éditeurs, par exemple, qui bien souvent se retrouvent modifiés directement dans leur code source (quand les sources sont disponibles) rendant ainsi toute montée de version insurmontable. Le but de le mettre dans un projet à part est le même que pour le framework, c’est-à-dire de pouvoir profiter des évolutions/corrections du produit proposées par l’éditeur en gardant la possibilité de changer simplement de version. Cette simplicité est accrue avec les qualité des interfaces que doit proposer le tronc commun pour accéder au produit. En effet, lors d’une montée de version, si quelques méthodes de l’outil ont changé, il suffira de mettre jour l’interface du tronc commun correspondante sans avoir à modifier un seul élément du Front ou du Back office.

Si il s’avère que des modifications sont nécessaires afin d’apporter quelques spécificités au produit, il faudra le faire dans un projet à part, en conservant la même logique arborescente que le produit lui-même. Les modifications seront fusionnées avec la version originale de l’outil lors de la phase de génération de la cible via le moteur d’automatisation des tâches.

Le contenu
Certains développements ont pour but de présenter du contenu. On peut prendre le cas d’un projet se basant sur un outil éditeur de type CMS (Content Management Systems ou Système de Gestion de Contenu). Du contenu sera nécessaire lors de la phase de développement. Cependant, le contenu doit se trouver impérativement dans un projet à part :

- pour identifier aisément les ressources « statiques » du site et les « dynamiques » correspondant au contenu,

- pour éviter lors des livraisons dans l’environnement de PROD d’embarquer des éléments de type contenu et d’écraser les modifications effectuées via le Back Office par les responsables du contenu (je suis sûr que si vous avez déjà travaillé sur un projet de CMS vous avez déjà vu ça… Hein !),

- pour ne pas mettre 3 heures à rapatrier votre projet de SVN/CVS (gestionnaire de sources) alors que vous ne vouliez récupérer que les fichiers sources du développement et que vous vous retrouvez avec 1Go de contenu en prime !

La compilation et l’exécution
La compilation des sources est assurées grâce aux dépendances que l’on peut appliquer entre projets. Il n’est donc pas nécessaire de tout mettre dans le même projet pour que cela compile ! ;ob Il faut cependant faire attention aux dépendances cycliques : bien que le compilateur refusera par défaut, il est toujours possible de désactiver certaines barrières, … Il est indispensable de ne pas en avoir car au-delà du fait que l’exécution ne sera pas possible sur l’environnement cible (rien que ça) à moins de tout poser au même endroit, cela signifie qu’il y a un problème de conception. Il n’y a pas de dépendance cyclique des projets si ils suivent une logique de couches correcte.

Concernant l’exécution, elle sera permise grâce à une tâche ANT qui va récupérer les compilés et ressources de chaque projet afin de les mettre à disposition dans un répertoire cible :

- répertoire du plugin Eclipse-Tomcat pour l’exécution en mode « débug »,

- version livrable sous forme de « war » pour plateformes d’INT, de PROD, …

- …

ANT est un scripteur de tâches permettant un ensemble complet de fonctionnalités (compilation, génération de Javadoc, archivage (zip, war, …), extraction CVS/SVN, …). Issu d’un projet Open source de la fondation Apache, il permet l’automatisation et donc la fiabilisation lors de la reproduction d’opérations répétitives tout au long du cycle de développement. Il sera alors possible de créer un ensemble de tâches ANT qu’il suffira d’exécuter : « Livraison DEV », « Livraison PRE-PROD », « Livraison PROD », …

ANT est capable également de se connecter à SVN et de générer les livrables à partir d’une version par exemple, une version des sources devant normalement être générée avant chaque livraison.

Si il est nécessaire d’avoir à disposition un ensemble de données d’initialisation du CMS pour le développement, un projet spécifique de contenu doit être créé et intégré via ANT lors de la génération du « build » dans la target « Livraison DEV ».

Illustration

Structuration-Organisation Projet

Conclusion
L’organisation d’un projet au niveau des sources est indispensable car c’est ce qui va vous permettre d’assurer une maintenabilité et une évolutivité de vos développements, vis-à-vis également des éventuelles montées de version des composants communs ou éditeurs sous-tendant votre projet.

De plus un moteur d’automatisation des tâches de développement est indispensable quelque soit la taille du projet afin de permettre une reproductibilité des tâches, d’assurer une capitalisation des connaissances via ces scripts et également de soutenir l’organisation projet des équipes en permettant, par exemple, à n’importe qui d’effectuer une livraison, et ce rapidement.

L’investissement au niveau de la conception est une économie au niveau du projet dans sa globalité.

Frédéric FAURE