Lorsque l’on arrive sur un projet qui a quelques difficultés, bien souvent, l’une des premières choses à faire est le bilan du projet. Cela passe par constater et, surtout, faire constater ce qui fonctionne aux différents acteurs de l’équipe : les développeurs bien sûr (qui devraient déjà avoir une idée sur la question) mais surtout aux chefs de projet fonctionnels voire même au client, qui ne manipulent pas le projet quotidiennement et pourraient en avoir une vision tronquée. Cette action capitale permet de discuter autour d’une base réelle et connue de tous, de rassurer ceux qui imaginaient le pire et de rétablir un dialogue constructif à travers toute l’équipe.

Pour cela, déployer l’application sur un serveur accessible par toute l’équipe est une étape primordiale : ce déploiement sera le point de départ du futur travail à effectuer, la remise à zéro des compteurs.

Afin d’être réactif, le (ou les) premier déploiement pourra se faire à la main, sans mettre en place de systèmes automatisés particuliers. En revanche, il deviendra vitre nécessaire de déployer régulièrement et automatiquement l’application. Cela permettra à toute l’équipe de constater les évolutions et de faire des critiques qui seront particulièrement utiles pour repérer les écueils à venir.

Dès aujourd’hui, …

Mardi, David Gageot a la dure tâche d’animer toute la soirée, dédiée aux tests et en particulier aux moyens d’accélérer l’exécution et le développement des tests. Voici un petit récapitulatif de la présentation de David.

Pourquoi rendre les tests plus rapides ? Pour accélérer le développement ! En gagnant du temps, je vais livrer plus souvent, vérifier la qualité plus souvent. L’intuition de David est que penser en avance à écrire des tests simples abouti à une application plus simple et de meilleure qualité. On suppose bien sûr que l’on es dans un contexte TDD où on lance les tests avant de commiter et qu’un serveur d’intégration continue build le projet et exécute les tests en continue.

Quoi ? tu testes pas ? t’es so 2010 ! On est en 2011, maintenant tu testes !

Dans ce contexte, s’il faut attendre des heures que les tests aient terminé de s’exécuter avant de pouvoir commiter alors la lenteur des tests devient un frein à la productivité. En plus, mécaniquement, chaque jour, la suite de tests est plus lente que la veille. Normal, le nombre de lignes de code et de lignes de tests augmente donc logiquement, ça prend …

Il y a de cela un peu plus d’un an, lorsque je cherchais un moyen de construire un plugin Eclipse avec Maven, je tombais presque par hasard sur une réponse laconique de Jason Van Zyl (le papa de maven): “Tycho”.
Mais, me diriez-vous : On ne pouvait pas contruire de plugin Eclipse avec Maven avant ???

Eh bien, en pratique, on pouvait parvenir à compiler des sources, à générer des fichiers manifest.mf voire à construire des “product” mais à quel prix ! A titre d’illustration, je vous invite à lire l’excellent article de Cyril Lakech et vous aurez une mince idée de la sueur et des larmes qu’il fallait accepter de verser pour mettre en place Maven sur des plugins avant d’apercevoir le graal.

Une autre alternative consistait à développer et maintenir ses propres “Mojo”; Grégory Levilain a ces dernières années ainsi développé et déployé sur de nombreux projets un ensemble de plugins Maven permettant d’adopter une optique “POM-FIRST”. Cette approche laisse à Maven le soin de gérer les versions des éléments du projet (plugins, fragments, features, update-sites, products), et de leurs dépendances. Ces travaux ont été initiés en 2006 lors de la mise en open-source du projet Wazaabi.

Mais alors …

J’ai eu l’occasion jeudi dernier d’assister à une présentation de l’outil de build Gradle par Hans Dockter, son fondateur. Cet événement était organisé par la société Zenika.

Dans son discours, Hans explique clairement avoir créé Gradle pour pallier au manque de flexibilité de Maven. Il souligne qu’avec Maven, on ne peut pas interagir avec les plugins, mais seulement les configurer de la façon spécifée. Ainsi, Gradle est un langage de build (et non un framework !) basé sur le principe qu’il est difficile de prévoir tous les scénarios auxquels nous pourrions être confrontés. Indéniablement, la présentation de Hans se déroule comme une partie de bras de fer avec Maven. Il anticipe immédiatement la question que tout le monde se pose : n’est-il pas risqué de s’affranchir des limites posées par Maven, sachant que c’est justement son caractère déclaratif et ses conventions qui en ont fait le succés, comparativement à ANT notamment ? A cette question Hans répond que nous sommes des informaticiens et que nous avons besoin d’outils pointus. “We need sharp tools”, dit-il.

Avec Gradle, les fichiers XML de ANT ou de Maven sont remplacés par …

L’essai brillamment marqué par l’équipe Ch’ti JUG lors de sa première session tenue il y a un mois est en passe de se transformer avec une seconde session le 15 juin qui s’annonce tout aussi passionnante.

Cette nouvelle session se focalise sur Maven 2 et les facteurs de réussite (et d’échecs) des projets qui en bénéficient. Pour en parler, c’est Arnaud Heritier qui se déplacera tout spécialement de la lointaine capitale jusqu’à Lille. Arnaud fait partie du comité de direction du projet Maven 2 chez Apache. Nous aurons donc, encore une fois grâce au Ch’ti JUG, l’information à sa source.

Les places disponibles pour l’événement restent limitées. Inscrivez vous donc très vite ici.