Suite à un commentaire sur l’article concernant les problématiques liées à la mise en place d’une usine logicielle pour mes applications Web J2EE, je vous fait part ici des éventuels débuts de réponses que je pourrais apporter à ces problématiques.

Ce précédent article date un peu, mais ces 3 dernières années ont été concentrées à répondre à ces questions que je m’étais posées à l’époque.

J’ai quelques articles plus complet en préparation à ce sujet, mais je n’ai malheureusement pas eu le temps de les finaliser pour vous les proposer. Cet article est donc une réponse intermédiaire.

Voici les solutions que nous avons pu adopter avec le temps.

• L’adoption de Maven comme nouveau standard de tous nos projets et migration des anciens projets . Quelques livres gratuits également pour comprendre Maven
• Un outil de gestion de projets et de tickets pour suivre tout l’historique  et les changements des projets. L’objectif de ces outils est de pouvoir répondre à tout moment à la question simple : pourquoi j’avais fait ça? Le plus connu de tous ces outils est probablement Jira, mais nous utilisons Redmine
• Pour la configuration sur les différents environnements, nous utilisons Spring Profile apparu depuis la version 3.1. Il permet de définir différents beans en fonction d’une variable d’environnement sur le serveur (Très pratique).
• Sur les projets utilisant Hibernate, on utilise une base de données H2 et Hibernate est capable de créer la structure à la volée, ce qui nous permet de faire des tests unitaires.  DBUnit charge quelques données  par défaut avant chaque test.
• Sur les projets non Hibernate, DBUnit doit permettre aussi de générer la structure d’une base vide.
• Jenkins nous permet de lancer tous nos tests unitaire, et nous l’utilisons également pour lancer nos déploiements sur les serveurs
• Sonatype Nexus est notre repository Maven, on y stocke chaque version compilé de nos war, ce qui nous permet en cas de problème de déployer très rapidement une précédente version.
• Enfin, nous utilisons le gestionnaire de source Git qui nous permet de gérer facilement différentes branches: nos travaux d’évolutions d’un coté et les  éventuels bugs que nous corrigeons.

Sur notre plus gros projet (plus de 600 000 lignes de code), nous somme arrivé en 3 ans à une couverture de test d’environ 50%. C’est peu, mais il n’y avait vraiment aucun test au départ. Toute nos nouvelles évolutions sont désormais couvertes à 100%. On était dans l’inconnu au début, mais c’est désormais très appréciable de savoir son code testé, on hésite moins à y revenir pour y ajouter de nouvelles fonctionnalités, les tests sont là pour détecter les régressions.

On passe bien évidement plus de temps initialement pour développer une nouvelle évolution. C’est vraiment très subjectif et cela dépend surement de notre projet, mais j’estime le ratio à une 1 journée de développement contre 2 jours pour réaliser les tests unitaires liés à la nouvelle fonction.

Les 50% de code non couvert correspondent principalement aux codes javascript et à l’interface web, nous n’avons pas encore abordé cette partie, mais nous pensons bien évidement à des solutions comme Selenium et/ou CasperJs.

En espérant que cet article apporte quelques pistes à vos réflexions.