Ce site met a disposition le build journalier de la traduction francaise du Maven: The Definitive Guide
Consultez :
  • Les documents de reference sur le projet original
  • Les sources de la traduction fr sur GitHub
  • maven


    Chapitre 5. Profils de Build

    5.1. À quoi servent-ils ?

    Les profils permettent d'adapter un build à l'environnement, ils assurent la portabilité entre différents environnements de build.

    Qu'entendons-nous par différents environnements de build ? La production et le développement sont deux environnements typiques. Quand vous travaillez dans l'environnement de développement, votre système est certainement configuré pour travailler sur une base de données de développement installée sur le poste local tandis qu'en production, votre système est configuré pour accéder à la base de données de production. Maven permet de définir différents environnements de build (profils de build) qui peuvent remplacer n'importe quel paramètre du fichier pom.xml. Vous pourriez configurer votre application pour lire dans votre base de données de développement locale dans un profil "development", et la configurer dans le profil "production" pour lire dans la base de données de production. Les profils peuvent également être activés en fonction de l'environnement et de la plateforme, vous pouvez personnaliser un build pour qu'il s'exécute différemment selon le système d'exploitation ou la version du JDK installé. Avant que nous parlions de l'utilisation et la configuration des profils Maven, nous devons définir le concept de Portabilité du Build.

    5.1.1. Qu'est ce que la Portabilité du Build ?

    La "portabilité" du build est la mesure de la facilité avec laquelle on peut prendre un projet particulier et le construire sur différents environnements. Un build qui fonctionne sans aucune configuration particulière ni personnalisation des fichiers properties est plus portable qu'un build qui nécessite un certain travail pour construire le projet à partir de rien. Les projets les plus portables sont bien souvent des projets Open Source très utilisés comme Apache Commons ou Apache Velocity qui fonctionnent avec Maven sans aucune personnalisation ou presque. Pour faire simple, les builds les plus portables fonctionnent immédiatement et les moins portables vous demandent de réaliser des acrobaties plus ou moins périlleuses dans les fichiers de configuration pour modifier les chemins vers les outils de build en fonction des plateformes. Avant que nous vous dévoilions comment obtenir un build portable, étudions les différents types de portabilité dont nous allons parler.

    5.1.1.1. Builds non portables

    L'absence de portabilité est exactement ce que les outils de build essayent d'éviter - cependant, n'importe quel outil peut être configuré pour être non-portable (même Maven). Un projet n'est pas portable lorsqu'il ne peut être construit que dans certaines circonstances spécifiques (ex : votre machine locale). À moins que vous travailliez seul et que vous n'envisagiez pas de déployer votre application sur une autre machine, il vaut mieux éviter complètement la non-portabilité. Un build non-portable fonctionne seulement sur une machine, c'est un build "à usage unique". Maven est conçu pour décourager les builds non-portables en offrant la possibilité de personnaliser les builds grâce aux profils.

    Quand un développeur récupère le code source d'un projet non-portable, il n'est pas en mesure de construire le projet sans remanier une grosse partie du script de build.

    5.1.1.2. Portabilité sur l'environnement

    Un build est qualifié de portable d'un environnement à l'autre s'il possède un mécanisme pour personnaliser son comportement et sa configuration en fonction de l'environnement. Par exemple, un projet qui contient une référence à une base de données de test dans un environnement de test et à une base de données de production dans un environnement de production, est portable sur ces deux environnements. Il est probable que ce build ait différentes propriétés pour chaque environnement. Quand vous changez pour un environnement qui n'est pas défini et qui ne possède pas de profil associé, le projet ne fonctionnera pas. Donc un projet n'est portable que sur des environnements bien définis.

    Quand un nouveau développeur récupère le code source d'un projet dépendant de l'environnement, il devra exécuter le build dans cet environnement ou créer l'environnement adéquat pour réussir à construire le projet.

    5.1.1.3. Portabilité interne à une organisation

    Le point clef de cet environnement est que seuls quelques-uns ont accès à des ressources internes à l'organisation, comme le gestionnaire de configuration ou le dépôt interne Maven. Un projet dans une grande entreprise peut dépendre de la présence d'une base de données accessible uniquement pour les développeurs internes. Un projet Open Source peut exiger un certain niveau de droits pour pouvoir publier le site web et les artefacts produits sur un dépôt public.

    Si vous essayez de construire un projet interne hors du réseau interne de l'entreprise (par exemple de l'autre côté du firewall), le build va échouer. Il se peut que cela vienne de plugins propres à l'entreprise qui ne sont pas disponibles ou de dépendances du projet inaccessibles car vous n'avez pas les droits nécessaires pour accéder au dépôt distant d'entreprise. Un tel projet n'est portable que sur les environnements au sein d'une organisation.

    5.1.1.4. Véritable Portabilité (Universelle)

    Tout le monde peut télécharger le code source d'un projet véritablement portable, le compiler et l'installer sans avoir à configurer le build pour son environnement spécifique. C'est le plus haut niveau de portabilité ; aucun travail supplémentaire n'est nécessaire pour construire ce projet. Ce niveau de portabilité est important surtout pour les projets libres qui dépendent de la facilité avec laquelle les contributeurs potentiels vont pouvoir construire le projet à partir du code source téléchargé.

    N'importe quel développeur peut télécharger le code source d'un projet véritablement portable.

    5.1.2. Choisir le bon niveau de portabilité

    Évidemment, vous voulez éviter le pire cas : le build non-portable. Vous avez peut-être connu le malheur de travailler ou d'étudier pour une organisation dont les builds des applications critiques sont non-portables. Dans une organisation comme celle-là, impossible de déployer une application sans une personne bien spécifique sur une machine bien spécifique elle aussi. Avec une telle organisation, il est très difficile d'introduire de nouvelles dépendances ou des changements sans se coordonner avec la personne qui gère ce build non-portable. Ces builds non-portables ont tendances à se développer dans des environnements très politiques où une personne ou un groupe veut contrôler quand et comment un projet est construit et déployé. "Comment construit-on le système ? Oh, nous devons appeler Jack et lui demander de nous le construire, personne d'autre ne peut déployer en production". C'est une situation périlleuse qui est beaucoup plus fréquente qu'on ne le pense. Si vous travaillez dans cette organisation, Maven et les profils Maven sont votre porte de sortie.

    À l'autre bout du spectre de la portabilité se trouvent les builds très portables. Ces builds sont des builds très difficiles à réaliser. Ils restreignent vos dépendances aux projets et aux outils qui sont librement distribuables et facilement accessibles. De nombreux packages commerciaux doivent être exclus des builds les plus portables car ils ne peuvent être téléchargés sans que vous n'ayez à accepter une licence spécifique. Cette large portabilité va également restreindre les dépendances aux logiciels qui sont distribués sous la forme d'artefacts Maven. Par exemple, si vous dépendez des pilotes JDBC d'Oracle, vos utilisateurs devront les télécharger et les installer manuellement ; ce n'est pas très portable car vous devrez fournir les instructions nécessaires pour configurer l'environnement afin que les personnes intéressées puissent construire votre application. D'un autre côté, vous pourriez utiliser un pilote JDBC disponible sur le dépôt public de Maven comme MySQL ou HSQLDB.

    Comme nous l'avons vu précédemment, les projets libres ont intérêt à avoir des builds le plus portable possible. Les builds très portables réduisent le coût de contribution d'un projet. Dans un projet libre (comme Maven), on trouve deux groupes d'utilisateurs très distincts : les développeurs et les utilisateurs finaux. Quand un utilisateur final utilise Maven et qu'il décide de contribuer en proposant un patch à Maven, d'utilisateur du produit final d'un build, il doit devenir capable de construire ce produit par lui-même. Il doit donc tout d'abord se transformer en développeur, mais il risque de perdre de sa motivation à contribuer au projet s'il dépese trop d'énegie à apprendre à le construire. Avec un projet très portable, un utilisateur n'a pas à connaître les arcanes du build d'un projet pour se transformer en développeur, il peut télécharger le code source, le modifier, construire son artefact et proposer sa contribution sans avoir à demander de l'aide pour configurer son environnement. Plus le coût d'entrée pour contribuer à un projet libre est bas et plus le nombre de contributions augmente, surtout ces petites contributions qui font la différence pour la réussite d'un projet. Une des conséquences de l'adoption de Maven par un grand nombre de projets Open Source est que contribuer à ces projets est devenu beaucoup plus facile.