Apache Maven dans un contexte professionnel

1. Le contexte

Les quatre premiers chapitres du livre ont permis de découvrir une première partie de ce que Apache Maven est capable de réaliser sur des projets informatiques Java. Toutes ces notions ont été abordées dans un contexte plutôt isolé.

En effet, en comparaison au schéma présenté en fin du chapitre Présentation d’Apache Maven - Maven au cœur de l’infrastructure projet, le schéma suivant représente la partie étudiée jusqu’à maintenant, où un développeur exécute des commandes Apache Maven sur son poste et télécharge, dans son référentiel local, les artefacts nécessaires pour le projet à partir des référentiels distants externes (Central, JBoss, etc.).

Toute la plus-value d’Apache Maven se mesure lors de sa mise en œuvre au sein d’un projet professionnel. La suite du livre, à commencer par ce chapitre, est donc axée sur ses fonctionnalités relatives à la collaboration d’une équipe de développement dans un contexte de projets professionnels.

Il est, par exemple, question de la configuration des postes de développement pour le fonctionnement d’Apache Maven dans les éditeurs de développement mais également de la mise en place d’Apache Maven...

1. Qu’est-ce qu’un SCM ?

Le terme SCM est principalement défini comme Source Code Management, c’est-à-dire le gestionnaire du code source du projet. Ce gestionnaire est généralement un des premiers éléments qui est mis en place lors du démarrage d’un projet.

L’utilisation d’un SCM est une pratique primordiale dans une équipe de développement logiciel puisque le code source est évidemment l’élément fondamental du projet.

Il existe de nombreux outils capables de réaliser de la gestion de code source, néanmoins quel que soit l’outil utilisé, il doit proposer les fonctionnalités de base suivantes :

Quelques SCM bien connus en entreprise depuis de longues années sont CVS (Concurrent Versions System) créé en 1990 et SVN (Subversion) créé en 2000. Aujourd’hui, un des SCM le plus récent est Git, qui a été créé en 2005.

Le principe de fonctionnement est le même pour tous les SCM et repose sur la notion de client et de serveur. La communication entre le client et le serveur se réalise à travers un protocole réseau supporté par le SCM. Certains SCM proposent également leur propre protocole de communication en natif, par exemple Subversion avec le protocole svn.

Il faut donc mettre en place un client pour le SCM, adapté au protocole utilisé, dans la configuration des postes de développement et sur les serveurs qui doivent communiquer avec le SCM.

2. Configuration des SCM pour Apache Maven

Les éléments du POM qui permettent de gérer les connexions au gestionnaire de code source du projet sont les suivant :

<project> 
 ...  
 <scm>  
   <connection>scm:...:...</connection> 
   <developerConnection>scm:...:...</developerConnection> ...

1. Les IDE et Apache Maven

Un IDE (Integrated Development Environment) se traduit littéralement comme un environnement de développement intégré. C’est-à-dire un logiciel qui va permettre au développeur de réaliser toutes une série d’opérations en rapport avec le développement logiciel dans une seule interface. Ainsi, il va lui permettre de s’affranchir de l’installation d’une multitude d’outils nécessaires au travail de développement sur le projet.

Aujourd’hui, les IDE aident considérablement les développeurs dans leur travail de tous les jours autour de Java. Avec l’avènement d’Apache Maven au sein des projets informatiques sont apparus depuis quelques années des plugins ou une implémentation en natif de Maven dans les éditeurs. Au départ assez instable, l’utilisation de Maven est désormais bien intégrée dans les IDE au sein des équipes projet.

Néanmoins, Il faut noter qu’au même titre que les autres fonctionnalités offertes par l’interface, il est fortement conseillé de maîtriser Apache Maven avant de l’utiliser dans un éditeur de développement intégré.

L’IDE Eclipse est présenté dans ce livre pour le développement de projets Java autour d’Apache Maven. Il correspond à l’outil le plus communément utilisé aujourd’hui pour le développement Java. Concernant les autres IDE comme NetBeans et IntelliJ, ils possèdent une intégration native de Maven et sont faciles à prendre en main à partir du moment où le développeur maîtrise correctement les concepts d’Apache Maven.

2. L’environnement de développement Eclipse

1. Introduction aux tests

La place des tests est fondamentale dans un projet de développement logiciel. Selon les démarches mises en place sur le projet, ils peuvent être le moteur (TDD : Test Driven Development) ou une composante du cycle de vie du projet.

Quelle que soit la philosophie mise en œuvre vis-à-vis des tests, il est question dans tout projet informatique de niveaux de tests pour différencier :

Au niveau des tests, Apache Maven ne gère nativement que les tests unitaires. En effet, son arborescence de dossier standard est telle qu’il y a seulement un point d’entrée pour tous les tests, à savoir ${project.basedir}/src/test/java et ${project.basedir}/src/test/resources. Néanmoins, il est possible de configurer le POM pour séparer les tests unitaires des tests d’intégration dans le cycle de vie d’un projet Apache Maven.

2. Les tests unitaires

Dans les premiers chapitres du livre tous les tests réalisés étaient des tests unitaires qui étaient appelés sur la phase test du cycle de vie du projet. Le chapitre Définition et cycle de vie d’un projet a mis en évidence que le plugin utilisé par défaut pour exécuter les tests est le maven-surefire-plugin. Il propose donc le MOJO surefire:test. Les rapports de tests sont générés dans le dossier ${basedir}/target/surefire-reports.

Dans les exemples du livre, l’implémentation mise en œuvre pour les tests est réalisée avec JUnit. Il est également possible d’utiliser le framework TestNG. Toute la documentation du plugin est à l’adresse : http://maven.apache.org/plugins/maven-surefire-plugin/

1. Présentation

Présentés brièvement au début du livre mais utilisés dans tous les exemples, les référentiels sont une autre des composantes indispensables au fonctionnement d’Apache Maven. Ils sont classés en deux catégories distinctes :

Une distribution d’Apache Maven installée sur un poste dont le référentiel local est vide et les référentiels distants inaccessibles ne peut fonctionner.

Il est important de noter qu’une configuration Apache Maven dispose uniquement d’un référentiel local mais utilise plusieurs référentiels distants avec des finalités différentes. Un référentiel est donc composé d’un ensemble d’artefacts. Selon les traitements à réaliser, Apache Maven va utiliser les référentiels en mode lecture, écriture, voire en mode suppression pour le référentiel local.

1. Présentation

Un gestionnaire de référentiels pour Apache Maven est un logiciel qui va permettre de centraliser et de masquer toute la complexité liée à ces dépôts de bibliothèques logicielles.

Il existe aujourd’hui sur le marché principalement trois logiciels qui assurent cette gestion dans les projets Apache Maven : Apache Archiva, Artifactory et Sonatype Nexus.

Le gestionnaire de référentiels mis en œuvre dans ce livre est Nexus.

2. Les avantages

La mise en place d’un gestionnaire de référentiels offre de multiples avantages pour l’équipe projet.

Un des atouts majeurs est le fait que les postes de développement ne sont plus dépendants de la connexion à Internet pour réaliser leurs traitements avec Apache Maven. En effet, c’est le gestionnaire qui est l’intermédiaire entre les référentiels distants sur le Web et les référentiels locaux sur les postes.

Le gestionnaire va également gérer un cache pour chaque référentiel distant afin de limiter les requêtes HTTP externes. Dans cette nouvelle configuration, un nouveau venu dans l’équipe de développement va pouvoir être rapidement opérationnel puisque toutes les dépendances nécessaires au fonctionnement du projet vont être téléchargées à partir du réseau interne de l’entreprise.

De plus, la configuration du poste du développeur et des POM est allégée puisque le nombre d’URL pour accéder aux référentiels est limité.

Entre autres fonctionnalités, le gestionnaire de référentiel permet également une gestion plus avancée des droits d’administration par référentiel.

La purge des artefacts dans les référentiels distants du projet peut être effectuée facilement et périodiquement. Enfin, le déploiement de bibliothèques logicielles...

1. Introduction

Depuis le début de ce chapitre, une des recommandations importantes conseillées est de ne pas déployer d’artefacts dans les référentiels à partir de postes de développement. Et pour cause, le déploiement d’artefacts est une des fonctionnalités dédiées à l’intégration continue.

L’intégration continue est un concept utilisée dans le développement logiciel pour définir une plate-forme centrale du projet qui réalise des traitements automatisés à intervalles réguliers afin de s’assurer, entre autres, du bon fonctionnement du code des applications, de sa qualité, et afin de le rendre disponible à l’équipe.

Pour réaliser ces opérations, une plate-forme d’intégration continue se base sur un logiciel dédié à ce métier. Dans le monde Java, et plus particulièrement pour Apache Maven, il existe plusieurs solutions logicielles pour les serveurs d’intégration continue, dont :

Jenkins/Hudson

Depuis janvier 2011, il existe deux serveurs d’intégration continue distincts basés sur le même code initial, alors qu’auparavant seul Hudson existait. C’est à la suite d’un conflit sur l’infrastructure du projet entre une partie de la communauté Hudson et la société Oracle, propriétaire du nom Hudson, que Jenkins a vu le jour. En effet, ce conflit ne trouvant pas d’issue, la communauté Hudson dans sa majorité a décidé de continuer le projet sous un autre nom, Jenkins, pendant que Oracle continue de développer Hudson.

2. Les avantages de l’intégration continue

L’intégration continue offre une multitude d’avantages dans un contexte de projets professionnels. Toutes les constructions des projets sont uniformespuisqu’elles sont toujours réalisées sur le même environnement et donc avec une configuration stable. Ceci évite les problèmes liés à l’archivage incorrect des projets pour les livraisons sur les plates-formes cibles.

Les constructions des projets sont automatisées et leurs...

1. Introduction

Le but ultime dans tout développement logiciel est à un instant donné de livrer le projet au client. Cette étape primordiale dans la vie d’un projet est généralement conduite par des objectifs ciblés sur des périmètres techniques et fonctionnels. Aujourd’hui, avec l’avènement des méthodes agiles, la livraison d’une application est devenue une tâche réalisée régulièrement dans la vie d’un projet.

Le terme général de livraison peut englober plusieurs éléments à destination du client, selon la nature des projets, dont :

Du point de vue de l’équipe de développement, ce processus de Release implique également des obligations techniques à respecter, telles que :

La phase de livraison d’un projet est donc une étape fondamentale pour un projet, Apache Maven mesure l’importance de cette étape en lui dédiant un processus strict : le processus de Release.

2. Gestion des numéros de version