Découpage modulaire d'une application Adélia

Une application est un ensemble de composants informatiques (ou modules) possédant des caractéristiques communes, offrant et utilisant des services (fonctions, procédures, types, etc.). Un composant applicatif est une représentation logique de l'application.

En Adélia, une application est définie au sein d'un environnement contenant l'ensemble des objets de celle-ci. Il est possible de regrouper ces objets au sein d'un ou de plusieurs domaines : chaque domaine définit alors un composant applicatif.

Lors de la phase de construction (build) des binaires de l'application, chaque composant est transformé en artéfact : l'artéfact est un livrable constituant l'application pour une version donnée. Enfin, chaque artéfact versionné est stocké dans un référentiel (repository) via un gestionnaire de livraisons. Ce référentiel a pour rôle de centraliser et de versionner l'ensemble des artéfacts produits par les développeurs.

↑ Haut de page

Les objets Adélia et les artéfacts associés

Chaque domaine Adélia regroupe un ensemble d'objets de nature différente (programmes, messages d'erreurs, états, ressources, classes, etc.).

De même, lors de la construction de l'application, chaque type de plateforme de génération produit des binaires de nature différente. Le processus de fabrication d'un artéfact dépend donc :

• du domaine Adélia,

• de la visibilité de l'objet (publique ou privée) dans le domaine,

• du type d'objet Adélia,

• du type de plateforme de génération.

Chaque artéfact regroupe donc les binaires issus de la génération d'objets de même type, appartenant à un même domaine, ayant la même visibilité, pour une même plateforme de génération.

Les types d'objets Adélia pris en compte lors du build d'une application sont les suivants :

Les objets Programme de type de source :

• Adélia,

• SAdélia (Serveur Adélia),

• VAdélia (Visual Adélia Batch et Interactif),

• WAdélia (Adélia Web batch et Interactif)

• Les objets Classe,

• Les objets services Web de type :

• DOCUMENT,

• DOCUMENT_JAXWS,

• REST

• Les objets Etats de type Crystal Report,

• Les objets Message d'erreur.

Les types de plateforme de génération pris en compte lors du build d'une application sont les suivants :

• Windows,

• Java (Standard et Cloud),

• AS400

Liste des types d'artéfacts produits :

Gradle et le build automatique d'artéfacts

Gradle (https://gradle.org/) est un outil open source de build à l'instar de Ant ou Maven.

Ces outils d'automatisation de construction de projet informatique s'appuient sur un processus qui peut se diviser en un certain nombre de tâches, dont voici les principales étapes :

• Préparation des fichiers de ressources, par exemple en adaptant les fichiers de propriétés à l'environnement cible (environnement de développement, d'homologation, de production...),

• Compilation des sources (Java, C, C++, etc.),

• Ces mêmes tâches sont ensuite exécutées sur les ressources et le code source des tests unitaires,

• Les tests unitaires sont alors exécutés sur le projet,

• Les livrables (JAR, WAR, EAR, ZIP, etc.) sont enfin créés, comprenant les binaires et les ressources du projet.

A ces tâches peuvent s'ajouter d'autres tâches supplémentaires, telles que :

• Déploiement du livrable ainsi créé, soit sur un référentiel général, soit sur un serveur d'applications (Tomcat, Glassfish, etc.),

• Création de rapports de qualité du code ( Sonar , Checkstyle , Cobertura , PMD , FindBugs , JUnit , etc.),

• Génération et déploiement du site du projet.

Gradle permet de définir les tâches (associées aux traitements à effectuer) de manière déclarative en utilisant un langage basé sur Groovy. Une tâche est définie par :

• son nom,

• son type (ex : Compile, Zip, Jar, Copy, JavaDoc, ProcessResources, Test, etc.),

• ses données d'entrée / ses données de sortie (ex : une valeur typée, un fichier, un répertoire, les données de sortie d'une autre tâche, etc.),

• sa configuration (par exemple : répertoire source, répertoire destination, options de compilation, etc.),

• sa dépendance à d'autres tâches,

• des traitements supplémentaires autres que ceux par défaut définis par le type de tâche.

L'ensemble des tâches définissent un projet Gradle et sont déclarées dans le fichier build.gradle.

Il est possible de définir pour le projet un ensemble de propriétés et constantes regroupées dans le fichier gradle.properties.

Gradle fournit un ensemble de plugins permettant d'étendre le modèle de base.

Chaque plugin apporte un ensemble de tâches qui lui est propre (ex : plugin Java pour la compilation, le test et le packaging de sources Java, Maven pour le support de la publication d'artéfacts vers les référentiels compatibles Maven, objective-c pour la compilation de sources Objective-C et le packaging de librairies natives, etc.).

L'exécution d'un projet de build Gradle se fait en lançant la tâche de plus haut niveau via la ligne de commande gradle nomDeLaTache.

Pour traiter cette tâche, Gradle :

1. calcule le graphe de dépendance des tâches à exécuter (la tâche de plus haut niveau définit en général un ensemble de sous tâches pour définir des traitements modulaires),

2. exécute chaque tâche du graphe. Si une tâche est en erreur, le build est stoppé.

Lors de l'exécution d'une tâche, Gradle gère un cache de ses entrées : si les données d'entrée sont identiques à celles de la précédente exécution et si les données de sortie n'ont pas été altérées, alors la tâche est considérée comme à jour (upToDate). Aucun des traitements associés à cette tâche n'est effectué.

Voici un exemple d'un certain nombre de lignes de commande Gradle :

Remarque : Dans la suite de l'aide, les exemples de ligne de commande Gradle s'appuient sur la commande gradlew.

L'utilisation de la commande gradle impose une phase d'installation manuelle de l'outil Gradle, alors que la commande gradlew (livrée dans Adélia Studio), permet une installation silencieuse lors de la première utilisation de l'outil Gradle.

↑ Haut de page

Prérequis au build Adélia par domaines

Un certain nombre de contraintes matérielles et d'architecture sont imposées pour l'exécution d'un build Adélia.

Prérequis du poste de build

Il est nécessaire de valider les conditions suivantes :

• Le poste qui exécute le build Adélia doit avoir Adélia Studio d'installé, avec l'option serveur de compilation (option d'installation par défaut),

• Les bases de données des environnements Adélia compatibles sont tous les gestionnaires de base de données supportés par Adélia, excepté Access, qui n'autorise pas d'accès multiples en parallèle,

• Le poste doit avoir un JDK 1.8 d'installé.

Prérequis d'architecture d'intégration continue

Le build Adélia s'inscrit dans une démarche plus générale d'intégration continue (continuous integration).

Celle-ci impose l'utilisation de gestionnaires de livraisons permettant de centraliser l'accès et le stockage d'artéfacts au sein de référentiels. Lors de l'exécution d'un build Adélia, ces référentiels sont utilisés de deux manières différentes :

1. Lors de la phase de construction des binaires, récupération à partir du référentiel Hardis des artéfacts du runtime Adélia nécessaires à la compilation (référentiel extérieur ou distant),

2. Lors de la phase de fin de build Adélia, utilisation d'un référentiel pour le stockage des artéfacts construits (référentiel personnel ou local).

Les gestionnaires de livraisons utilisés à cet effet doivent être compatibles Maven à l'instar des produits Nexus (https://www.sonatype.com/nexus-repository-oss) ou Artifactory (https://www.jfrog.com/artifactory/).

La suite de la documentation s'appuie sur le produit Sonatype Nexus.

Pour simplifier l'architecture, il est possible d'utiliser un seul gestionnaire de livraisons : celui-ci peut être configuré pour être compatible avec les deux types de référentiels utilisés lors des deux phases décrites plus haut.

Après installation du Nexus, celui-ci offre par défaut les référentiels suivants, accessibles via la vue "Repositories":

• Le référentiel de nom "Central", défini comme une passerelle (ou proxy) vers le dépôt distant Maven Central : celui-ci regroupe un très grand nombre d'artéfacts open source (notamment les artéfacts utilisés par le runtime Adélia),

• Le référentiel de nom "Releases", défini comme un référentiel local pour le stockage des artéfacts en version release,

• Le référentiel de nom "Snapshots", défini comme un référentiel local pour le stockage des artéfacts en version snapshot.

A partir de cette vue, il faut ajouter un nouveau référentiel défini comme proxy du référentiel distant Hardis :

• Ouvrir la fenêtre de définition d'un référentiel via la commande "Add proxy repository",

• Dans la section "Remote storage location", saisir l'URL https://pid.hardis.fr/nexus/content/groups/HardisISV/ ,

• Cliquer sur "Authentification (optional)" et renseigner les champs "Username" et "Password" avec les valeurs "adelia" et "readonly" (identifiants de connexion au référentiel Hardis),

• Dans la phase de configuration du projet Adélia build, il faut remplacer, dans le fichier gradle.properties, la valeur de la clé downloadArtifactsRepo par l'URL "Repository Path" du référentiel passerelle nouvellement créée.

De même pour définir les référentiels locaux pour le stockage des artéfacts construits, il est possible de :

• soit utiliser les deux référentiels prédéfinis "Releases" et "Snapshots",

• soit ajouter deux nouveaux référentiels locaux (via la commande "Add hosted repository").
  Celui destiné à stocker les artéfacts en version release doit avoir le champ "Repository policy" à la valeur "Release" et celui pour les versions snapshot à la valeur "Snapshot".

Dans les deux cas, lors de la phase de configuration du projet Adélia build, il faut remplacer dans le fichier gradle.properties la valeur des clés uploadArchivesReleaseRepo et uploadArchivesSnapshotRepo par la valeur du champ "Repository Path" des référentiels release et snapshot.

Par défaut, Nexus définit pour ces référentiels des identifiants de connexion deployment-  / deployment  (ayant les droits d'écriture).

↑ Haut de page