Journal de bord
Cette page est destinée à expliquer les choix techniques, la méthodologie employée pour comprendre, déployer et tester ce projet.
//EXPLIQUER L UTILISATION DE GITHUB ET PAS GITLAB
Nous avons voulu dans un premier temps comprendre comment fonctionnait l'application. Comme il n'y a pas de documentation ni de README, nous avons observé le schéma de la base de donnée. Celui-ci à pu nous apporter beaucoup d'informations sur :
- Le but de l'application
- Les entités et leurs relations
- Le fonctionnement primaire
Nous nous sommes en suite penché sur le code. C'est un code simple, daté et donc non maintenu. Il n'y avait aucune documentation technique sur comment lancer le projet. En plus de ça, nous nous sommes rendu compte de certains problèmes sur l'api.
Parmi les problèmes :
- Mettre à jour un sondage.
- Des méthodes GET qui retourne des listes vides au lieu d'indiqué que la ressource demandé n'existe pas.
- Certaines méthode retourne des erreurs 500.
Dès le début du projet, nous avons mis un poing d'honneur à faire en sorte que notre projet soit facilement déployable sur beaucoup d'environnement. Nous avons alors pensé à 2 stratégie :
- Utilisation des outils de Springboot
- Utilisation de Docker Ces deux stratégies sont très différente et sont complémentaire. L'une permet d'installer le projet de façon classique avec un petit peu de mise en place alors que l'autre solution est une solution "clés en main" sous condition d'avoir Docker installé sur sa machine.
Pour l'installation de ce projet au local, Springboot fourni une documentation présente ici.
Celle-ci indique l'utilisation de fichier nommé "application.properties" qui permettent de donner des variables à notre projet afin qu'il puisse s'exécuter proprement. (Ex: Lien de la base de donnée, Driver de la base, etc...)
Mais également, elle permet d'indiqué le profil de l'application, il s'agit d'une variable qui va indiqué si le projet tourne dans un environnement local, de test ou encore en production. Cela permet à l'application de rechercher d'autres variables d'environnement spécifique à chaque profil (Ex: profil=local, alors le fichier application-local.properties sera utilisé). Le but étant d'affiner ces variables en fonction de chaque environnement d'éxecution.
Le déploiement en local nécessite de la mise en place afin de pouvoir correctement s'éxecuter. En effet, la machine doit posséder :
- JAVA Version 19+
- Une base de donnée
- Serveur HTTP (Type : nginx ou apache) Dans le cas du déploiement sur un serveur à distance.
Comme expliqué précédemment, nous avons préparé une configuration Docker permettant à l'utilisateur une solution "clés en main". Celui-ci n'a besoin d'avoir sur sa machine que le programme Docker. Cela nous permet de lancer le projet d'une seule ligne de commande
docker-compose up -d --buildCelle-ci va utiliser le fichier docker-compose.yml et le Dockerfile afin de créer un environnement virtuel (un container) configurant automatiquement :
- JAVA 19
- Une base de donnée Et permettant au connexion externe de se connecter au projet par un port définis dans la configuration .env du projet.
Pour notre projet, nous avons décidé d'utiliser une base de donnée Postgres dans la configuration Docker. Celle-ci est accessible en dehors du conteneur de base mais il est facilement modifiable afin d'éviter cela.
Lors de la mise en place de ce dernier, nous avons rencontré quelques problèmes sur l'utilisation des variables partagés. Comme dans la configuration précédente, il est possible d'intégrer des variables d'environnement propre au projet (Ex: Changer le profil de l'application ou encore l'url de la base de donnée).
Le fonctionnement sera le même en Local ou sur un Serveur (Il faut tout de même un serveur HTTP sur le serveur). Une feature est également ajouté en Local (Sur machine perso) : Adminer, un interface de gestion de base de donnée très léger.
Pour déployer sur notre environnement public, nous possédions déjà un serveur (VPS) loué chez OVH ainsi qu'un nom de domaine. Le serveur possède un serveur HTTP nginx et est sécurisé à l'aide plusieurs système.
Sur le serveur le projet tourne sur l'environnement Docker et tout les ports autres que HTTP et SSH sont fermés.
Nous avons alors créer une GitHub Actions de CD permettant de faire un déploiement automatique sur le serveur grâce à une authentification à l'aide de clef ssh.
Cette Actions se connecte donc au serveur, éteint temporairement le projet, effectue un git pull et redémarre le conteneur avec les changements.
Comme nous utilisation Github, nous avons accès à GitHub Pages en suivant ce tutoriel. Ce dernier va nous servir afin de publier les rapports de Coverage de Jacoco et PiTest.
Comme vous pouvez le voir ici :
Coverage Jacoco (Vous pouvez cliquer) : 
C'était le type de tests dont nous avions le moins de mal à imaginer et à implémenter. Ce sont les premiers qui ont commencé à émerger dans le projet relativement simplement. C'est également le seul type de tests que nous avions déjà effectué sur des projets. Ces tests nous ont guidé tout le long du projet, notamment à l'amélioration de la qualité du code grâce aux Mutations de Pitest et au Coverage de Jacoco.
Nous effectuons nos tests unitaires sur les services et les controllers. Nous ne testons pas la configuration car ses erreurs se verraient au niveau du build ni le main pour les mêmes raisons. Quant aux modèles et DTO, nous ne les testons pas car les méthodes sont appelées et donc testées directement depuis les services. Faire cela permet également lors du coverage de repérer les bouts de codes qui ne sont jamais atteints et donc, jamais utilisés.
Nous avons décidé, après concertation, de ne pas effectuer de tests d'implémentation. Dans un premier lieu, nous avons essayé d'en faire en mockant la base de donée grâce à MockMVC. La configuration fut compliquée et l'on s'est finalement rendus compte que ces tests allaient se confondre avec les tests E2E, qui effectuent la même chose en plus de tester les ajouts à la base de données et les codes de retour HTTP. Nous avons donc décidé de ne pas effectuer de tests d'implémentation pour ce projet.
Nous avons effectué quelques recherches pour savoir comment exécuter des tests E2E car nous n'en avions jamais fait jusque là, il nous a été compliqué dans un premier temps de comprendre comment les effectuer alors que nous n'avions pas d'interface graphique. Jusque là, les tests E2E ne représentaient que des tests de clics sur une interface graphique. Par la suite, nous avons compris qu'il fallait créer des scénarios qui permettaient d'exécuter le code qu'effectuerait ces tests de clics.
Ces tests ont été très longs à implémenter, assez chaotiquement. Notre méthode de travail aurait pu être plus optimale à ce sujet. Nous avions un mode de fonctionnement hybride avec du Test-Driven-Development. On effectuait des modifications dans le code à mesure que les tests échouaient et l'on a repéré beaucoup de codes HTTP renvoyés mauvais ou des fonctionnements peu intuitifs ou ne fonctionnant pas du tout. Également, le fait que nous avons choisi de faire des scénarios, et donc des tests qui découlent des uns des autres fut horrible à corriger car une erreur en produisait 4 supplémentaires.
Au final, ces tests ont demandé un temps important de développement, peut-être un peu trop ? Ils ne testent pas non plus tous les cas mais ils nous ont permis de grandement améliorer la qualité de code, tester les fonctionnalités et s'assurer qu'elles fonctionnent dans leur comportement "normal".
Vous pouvez consulter cette partie ici