Skip to content

Journal de bord

HiroKX edited this page Jan 18, 2024 · 18 revisions

Introduction

Cette page est destinée à expliquer les choix techniques, la méthodologie employée pour comprendre, déployer et tester ce projet.

Code existant

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.

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

API

Déploiement

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 :

  1. Utilisation des outils de Springboot
  2. 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.

Local

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 :

  1. JAVA Version 19+
  2. Une base de donnée
  3. Serveur HTTP (Type : nginx ou apache) Dans le cas du déploiement sur un serveur à distance.

Docker

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

Celle-ci va utiliser le fichier docker-compose.yml et le Dockerfile afin de créer un environnement virtuel (un container) configurant automatiquement :

  1. JAVA 19
  2. 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.

Environnement public

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.

Github-pages

Tests

Tests unitaires

Tests d'implémentation

Tests E2E

Nous avons assez rapidement séparé les tâches pour déployer tous les types de tests en même temps. 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

Code Coverage et qualité de tests

Vous pouvez consulter cette partie ici

Clone this wiki locally