Twelv : De l'idée à la production

REX sur l'utilisation de JHipster jusqu’à la production

Ce post fait suite à un webinar qui présente les enjeux business et l'architecture du projet que vous pourrez trouver ici. Il a pour but de donner plus de précisions sur les aspects techniques du projet.

Dans cet article, je vous propose d’aborder le contexte de mon premier projet chez Ippon, ainsi que ma première réelle utilisation de JHipster.

Twelv est une méthodologie ayant pour but d’accélérer la transformation digitale de sociétés en leur proposant une approche collaborative de la formation. (Je vous invite à aller voir leur site vitrine)

Afin d’accompagner leur premier client dans sa transformation, les créateurs de Twelv ont souhaité une plateforme simplifiant la gestion des formations, et invitant les collaborateurs à s’impliquer dans le processus de transformation numérique de leur société.

JHipster késako?

JHipster est un générateur d’application basé sur Yeoman, permettant de simplifier la création, le développement et le déploiement d’applications Web en utilisant Spring Boot (ou encore NodeJS, .Net et bien d'autres ) pour la partie back-end et proposant le choix entre plusieurs frameworks pour la partie front-end (Angular, React, Vue.js, …).

De nombreux modules et blueprints permettent d’étendre les possibilités de JHipster, mais vous en apprendrez bien plus sur le site officiel.

Le rôle de la plateforme

Les principaux besoins auxquels doit répondre la plateforme sont :

  • Permettre aux responsables du cycle de formation (les pilotes) de gérer l’ensemble des sujets, supports et sessions de formations
  • Pousser les utilisateurs à participer activement à la transformation de l’entreprise. Notamment à suivre des sessions de formations mais aussi à en animer, créer des supports de formations et enfin, donner leur avis sur chaque session suivie.
  • Générer différents KPIs afin que le pilote puisse améliorer les runs et les formations de façon incrémentale. C’est aussi grâce à ces indicateurs que l’équipe Twelv mesure l’utilisation de la méthode et l’implication de la communauté, afin de facturer leur prestation.

Déroulement du projet

L’équipe en charge de développer ce projet était composée d’un développeur, un architecte présent à temps partiel ainsi qu’un stagiaire arrivé durant la phase de développement.
Le temps imparti pour mener à bien ce projet a été assez court mais bien rempli, la phase de développements “pure” ayant duré moins de 3 semaines. En voici un aperçu :

Twelv-timeline-large

Un enjeu majeur : le gain de temps

mur-backlog-1-1

Le principal enjeu du projet était le respect de la deadline. Nous avons commencé à recueillir les besoins fin janvier pour une mise en production le 3 mars.

Il a donc fallu travailler vite, que ce soit au niveau de l’expression des besoins, des développements ou encore des déploiements.

Pour l’expression des besoins, nous avons travaillé en méthode AGILE afin de permettre au client de s’exprimer dans un cadre collaboratif et créatif. Les créateurs de Twelv ne viennent pas du monde informatique et ne connaissaient pas cette manière de travailler. Celà leur a plu, et ils ont été très proactifs lors de l’écriture des stories. De plus, travailler ensemble avec eux nous a permis de cadrer leurs besoins en leur expliquant comment nous allions travailler et qu’il fallait prioriser les fonctionnalités créant une réelle valeur, avant de penser aux petits ajustements qui ne sont pas forcément nécessaires sur une première version. Nous échangions régulièrement avec le client, afin de leur dire où nous en étions, leur montrer l’état de l’application et les fonctionnalités implémentées, ainsi que pour leur poser des questions si certains points nous semblaient flous. Cette façon de travailler nous a aussi permis de prendre en compte les retours client au fil de l’eau et ainsi ne pas perdre de temps à la fin du projet.

Pour les développements, nous avons souhaité utiliser JHipster afin de nous faciliter la mise en place du socle technique ainsi que des différentes entités, les tests, et toute l’aide qu’apporte JHipster sur les développements.

Pour le déploiement, le choix s’est vite porté vers une solution cloud, car le temps était compté et le client ne disposait ni de serveurs, ni de locaux. L’utilisation d’AWS, notamment grâce au générateur JHipster, nous a fait gagner du temps et a évité les complications liées à la mise en place d’un serveur “on premise”, le tout pour un prix extrêmement contenu, notamment pour une start-up.

L’utilisation de JHipster

Choix de génération

La plateforme finale étant finalement une application web classique. Nous sommes partis sur une application monolithe, avec une base de données Postgresql en production et un front-end en Angular.

JDL & entity sub-generator

La phase de cadrage et de définition des besoins ayant été assez longue par rapport aux délais imposés, nous avons construit une JDL au fur et à mesure des ateliers. Ainsi nous avons juste eu à utiliser le générateur JHipster afin de construire les scripts Liquibase, les entités et tous les fichiers correspondants.

JHipster propose un outil en ligne nommé JDL-Studio qui permet de décrire le modèle de données en inscrivant simplement le nom de chaque entité, les champs qui les composent ainsi que les relations entre elles. Le Studio affiche le MLD en temps réel et permet de télécharger le fichier au format JDL (JHipster Domain Language) ainsi créé, afin de l’utiliser directement à l’aide du sub-generator ainsi :

$> jhipster import-jdl my-jdl.jh

Cette commande génère les fichiers Liquibase permettant l’ajout des tables en base de données, les entités Java, les JPA Repositories, les Controllers Rest, les composants Front (Liste, Ajout, Suppression, Modification) ainsi que des tests front-end, back-end et end-to-end. Il est important de noter que la couche de service n’est pas générée dans ce mode, ainsi les controllers REST utilisent directement les JPA Repositories.

Nous avons tout de même eu besoin de modifier ou ajouter des entités. Nous avons pu, à ce moment, utiliser l’entity sub-generator afin de simplifier les modifications à effectuer. Il est possible, dans ce mode, de générer une couche de service si nécessaire.

Cependant, les scripts Liquibase sont écrasés (la modification de la base de données n’est pas incrémentale) et certains fichiers modifiés peuvent être écrasé. Il faut donc être prudent, et préférer effectuer ces modifications manuellement, lorsqu’elles ne sont pas trop lourdes (modification ou ajout d’un champ, par exemple)

JDL-studio

GitLab-CI

JHipster permet de mettre en place simplement une intégration et un déploiement continu via les pipelines GitLab-CI. Ainsi nous avions créé différents jobs.

Maven-compile : Compilation en mode production du projet
Maven-test : Tests Back-end
Frontend-Test : Tests Angular
SonarQube : Analyse de la qualité du code
Maven-package : Création du package en mode prod
Deploy : Déploiement sur l’environnement de production (via jhipster-aws)

Développement des fonctionnalités

De nombreuses fonctionnalités concernaient simplement des besoins CRUD :

  • Lister les entités
  • Voir le détail d’une entité
  • Créer une nouvelle entité
  • Modifier une entité
  • Supprimer une entité

Ainsi, pour certaines fonctionnalités, nous avons simplement remanié les pages générées par JHipster afin de n’afficher que les informations pertinentes, et répondre plus précisément aux besoins du client.

C’est sûrement sur ce point, la génération des entités via JDL, que l’utilisation de JHipster nous a été le plus utile.

Un déploiement dans le cloud

Afin de répondre aux besoins du client, qui souhaitait une plateforme disponible rapidement, à bas coût, avec le moins de maintenance possible, nous avons décidé de partir sur une solution cloud, et dans notre cas AWS.

Le générateur jhipster-aws nous a donc été d’une grande utilité, ce dernier permettant de gérer de façon simplifiée le déploiement d’une application sur AWS. Ainsi, les différentes évolutions ont pu être déployées par quelques clics depuis les pipelines gitlab-ci.

pipeline

Le défaut du générateur AWS est que cette solution n’est cependant pas adaptée pour la coexistence de plusieurs environnements (Prod, Préprod, …) sur un même compte AWS, et c’est une des évolutions majeures que nous devrons analyser rapidement.

Conclusion

A la lecture de cet article, vous n’avez peut-être pas saisi tous les gains apportés par l’utilisation de JHipster sur un tel projet. En effet, son utilisation est très simple et finalement, il n’y a que peu de choses à dire sur son utilisation, vu le peu de questions qu’on se pose.

L’initialisation du projet simplifiée

Pour simplifier mon point de vue, l’initialisation d’un projet JHipster peut être faite en une journée si votre schéma de données et déjà prêt :

  • Création du schéma initial avec le JDL studio
  • Génération des sources Front/back avec de nombreuses fonctionnalités CRUD déjà implémentées
  • Génération des tests Back-end, Front-end et end-to-end
  • CI/CD via Gitlab-CI
  • Déploiement sur AWS

Ce temps gagné nous a permis d’avancer sur des fonctionnalités qui n’étaient pas dans le périmètre du MMP (Minimum Marketable Product = Produit contenant les fonctionnalités minimales indispensables à la présentation du produit aux clients), et de passer plus de temps à redéfinir les besoins réels. Nous avons eu des retours clients très positifs sur l’application, que ce soit au niveau design, fonctionnalités, coût ou encore au niveau des méthodes de travail.

Mon utilisation de JHipster pour la suite

JHipster est donc un outil dont le peu de défauts sont gommés par ses qualités, et j’ai décidé de reprendre entièrement un projet perso qui dormait depuis quelques temps, via JHipster.
Cependant, suite à cette première utilisation de JHipster, je vais générer la JDL la plus complète possible et me servir de JHipster pour la génération initiale du projet ainsi que la création de nouvelles entités. En effet, la modification d’entités existantes me semble plus simple à effectuer manuellement, afin d’éviter d’écraser des traitements custo, et de gérer Liquibase de façon plus incrémentale.

Pour la suite à Ippon Toulouse, nous avons un client intéressé par une application mobile (iOS et Android), nous allons donc étudier la piste du générateur Ionic pour JHipster.