Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Apache Maven
  3. Apache Maven dans un contexte professionnel
Extrait - Apache Maven Maîtrisez l'infrastructure d'un projet Java EE (2e édition)
Extraits du livre
Apache Maven Maîtrisez l'infrastructure d'un projet Java EE (2e édition)
1 avis
Revenir à la page d'achat du livre

Apache Maven dans un contexte professionnel

Introduction

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.).

images/05EP01N.png

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...

Apache Maven et les SCM

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 :

  • Fournir un emplacement de stockage pour le code source.

  • Proposer un historique de ce qui a été réalisé au fil du temps.

  • Mettre à disposition un système pour que les développeurs puissent travailler en parallèle puis fusionner leur travail par la suite.

  • Donner la possibilité aux développeurs de travailler sans se gêner les uns des autres.

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> ...

Les environnements de développement

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

a. Présentation

Eclipse est l’environnement de développement intégré le plus utilisé dans le monde Java. Il est développé en Java et est extensible par la notion de plugins.

Eclipse est à la base un projet développé chez IBM qui est passé dans le monde Open Source en 2001. La fondation Eclipse est créée en 2004.

La fondation Eclipse sort une nouvelle version majeure de sa plate-forme...

Apache Maven et les tests

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 :

  • Les tests unitaires.

  • Les tests d’intégration techniques et fonctionnels.

  • Les tests de recette.

En France, le CFTL (Comité Français des Tests Logiciels), créé en 2004, réunit des experts des tests logiciels et propose des formations et des certifications. Il définit également des normes pour l’ensemble du domaine du test logiciel.

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/

a. Exécuter un seul test d’une classe de tests

Depuis la version 2.8.1 du plugin maven-surefire-plugin, il est possible de préciser le nom de la méthode à exécuter dans une classe...

Les référentiels Apache Maven

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 :

  • Les référentiels distants.

  • Le référentiel local.

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.

a. Le référentiel local

Le premier chapitre du livre a mis en valeur l’élément dans le fichier settings.xml qui permet de configurer l’emplacement du référentiel local.

Le référentiel local est constitué dans sa plus grande partie des artefacts téléchargés à partir des référentiels distants, et des projets en cours de développement copiés par le MOJO install:install pour l’autre partie.

Le référentiel local doit être considéré comme un emplacement de stockage temporaire qui peut être par conséquent vidé de son contenu sans conséquence majeure. Il ne doit en aucun cas contenir des données du projet non stockées dans un emplacement de sauvegarde officiel de l’infrastructure (SCM).

b. Les référentiels distants

Depuis le début du livre, les référentiels distants n’ont eu d’autre utilité que de remplir le référentiel local d’artefacts pour permettre à Apache Maven et aux projets de fonctionner correctement.

Dans un contexte de projets professionnels et de travail en équipe, ils sont complétés par des référentiels...

Les gestionnaires de référentiels Maven

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.

Une comparaison des fonctionnalités offertes par ces 3 gestionnaires de référentiels est disponible à l’adresse suivante : https://binary-repositories-comparison.github.io/. Elle est régulièrement mise à jour.

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...

L’intégration continue

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...

La phase de livraison du projet : la Release

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 :

  • L’application stable sur un périmètre technique et fonctionnel précis.

  • La documentation technique du projet.

  • Le code source du projet.

  • Les rapports techniques sur la qualité du projet.

  • La documentation pour les utilisateurs de l’application.

  • Le guide d’installation de l’application.

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

  • Les livrables doivent être sauvegardés.

  • Le code source qui a permis de réaliser ces livrables doit être sauvegardé et clairement identifié dans le gestionnaire de source.

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

a. Définition générale

Dans le monde du développement logiciel, la notion qui ne peut pas être décorellée de la livraison d’un projet est celle de la gestion des numéros de version. En effet, c’est l’identifiant déterminant qui permet de faire la relation entre le nom d’un livrable et son contenu technique et fonctionnel.

De plus, le numéro de version doit respecter des normes précises afin de visualiser rapidement l’intérêt d’une livraison en comparant les numéros de deux livraisons successives. En effet, la livraison d’un projet peut être réalisée pour répondre à...

En résumé

La mise en place d’une infrastructure complète autour d’Apache Maven sur un projet professionnel se réalise en plusieurs étapes.

L’idée principale de ce chapitre réside dans le fait qu’il est essentiel de maîtriser les principes de base d’Apache Maven expliqués au début du livre avant de mettre en place tous ces outils qui permettent d’automatiser le travail en équipe.

L’ajout d’un gestionnaire de référentiels pour les artefacts apporte une vraie plus-value sur le projet. Néanmoins, dans un premier temps, si l’infrastructure ne le permet pas, il est possible de gérer de manière structurée et sécurisée ses référentiels distants avec un simple serveur Apache HTTPD.

La mise en place de l’intégration continue est quant à elle nécessaire dès le début du projet. Elle assure une homogénéité des artefacts déployés qui est primordiale au bon fonctionnement du projet.

Que ce soit pour l’utilisation des plugins Maven dans les éditeurs de développement ou la gestion des référentiels par une application dédiée ou l’intégration continue, il faut avant tout savoir pourquoi ils sont utiles et comment les mettre en place pour améliorer le quotidien...