complete the information in the CI/CD report

README.md

@@ -2,6 +2,8 @@
 
 Pour jouer, rendez-vous sur https://kwisos.servegame.com/
 
+_En raison d'un problème de sockets sur le vps qui héberge le site, les modes timer, scrum et team sont à tester en localhost_
+
 ## Introduction
 
 KWÌZØS est une application de quiz interactive qui permet aux utilisateurs de jouer à des quiz en ligne. Ce projet comprend une API, un client web et une application mobile.

rapport.md → rapport-A52.md

@@ -8,6 +8,8 @@ L'objectif du projet est de créer une application web et mobile communiquant av
 
 La pipeline se connecte via une clé SSH à notre VPS, y envoie une version compressée du projet, la décompresse puis lance des Docker. Ces Docker build l'API et l'application web pour les rendre accessibles et optimisées sur le VPS. Grâce aux clés SSH, c'est sécurisé. Avec les Docker, c'est facile. En compressant, cela permet de réduire drastiquement la quantité d'espace disque utilisé : un élément très important pour nous puisque nous utilisons jusqu'à la version finale exclue un VPS avec très peu d'espace disque.
 
+La pipeline n'a plus ni linting, ni test, pourquoi ? Les tests automatisés (unitaires, d'intégration, ...) sont pratiques sur la longueur, pour s'assurer du bon fonctionnement de l'application. Cependant, ils rajoutent une charge supplémentaires de travail lors de leur écriture, mais aussi sur la durée puisqu'ils faut les mettre a jour régulièrement en même temps que l'appli elle-même. Nos délais étant très serrés, nous devions constamment ajouter des fonctionnalités, sans le temps d'écrire des tests adaptés pour toutes. Quant aux grosses fonctionnalités, d'une complexité élevée ou avec un impact fort sur l'application, ils ont d'abord eu le droit à leur test unitaires et d'intégrations, avant de devoir être retirés, car trop obsolètes et par manque de temps pour les mettre à jour. L'approche Test driven development, étudié pour l'API au départ du projet, n'a dès lors pas été maintenue. Quant au linting, l'ajout d'husky (node module) permets d'appliquer automatiquement un formattage et applciation du linting de code au moment d'actions, de hooks git (commit, push, ...), supprimant le besoin de rejeter du code si celui-ci n'est pas assez bien formatté.
+
 ### Image Docker
 
 Les docker build l'api et le web et les expose sur les ports du pc. le docker compose orchestre leur execution et leurs variable d'environement.
@@ -53,7 +55,7 @@ Voici le workflow, dispo sur notre confluence ( <https://glazk.atlassian.net/wik
 
 - Faite un `git switch feature-xxx`
 
-- Bossez et commitez dessus
+- Travaillez et commitez dessus
 
 ### Une fois la tâche terminée
 
@@ -73,7 +75,7 @@ _Votre tâche sera validée ou non par votre reviewer, qui mettra en commentaire
 
 ### Branches
 
-- master
+- main
 
 - develop
 
@@ -127,6 +129,10 @@ Voici l'extrait de notre Confluence <https://glazk.atlassian.net/wiki/spaces/DL/
 
 - Composants React `.tsx` : `MyReactComponent.tsx`
 
+- Dossier des side-end (fronts, back) : NameOfMyAPI, NameOfMyFrontWeb, ...
+
+- Sous-dossier : sous_dossier
+
 ### Repo
 
 Un repository unique. Pas de fork.
@@ -135,7 +141,7 @@ Toujours faire des merge request
 
 ####  Branches
 
-- master
+- main
 
 - releases (pour les versions prêtes, à rendre, aka v0, v1, v2, ...)
 
@@ -149,11 +155,7 @@ Toujours faire des merge request
 
 ####  Commits
 
-##### Merge sur develop
-
-- pour les nouvelles feature : `add feature nom_de_la_feature`
-
-- pour les corrections : `fix ce_qui_est_corrigé`
+Messages libres, pas de limitation particulière mais soyez précis et granulaire dans ce que vous avez fait, et éventuellement la raison de ce changement/ajout/suppression.
 
 ###  Contenu du repo
 
@@ -163,10 +165,16 @@ Toujours faire des merge request
 
 - ZmeiDB (api et db)
 
+### Info sensibles
+
+- Assurez-vous qu'aucune information sensible n'apparaît dans le dépôt ou sur GitLab.
+- Pour les fichier d'environnements (.env), voyez avec le responsable du side-end associé (Samuel pour l'api, Jovanny pour le mobile, Maxime pour le web)
+
 ```
 
 6. **Informations sensibles :**
-   - Vérifiez et assurez-vous qu'aucune information sensible n'apparaît dans le dépôt ou sur GitLab.
+   - Les variables d'environnement, mot de passe, etc devaient passer uniquement sur des canaux de messagerie privés.
+   - Ayant eu des problèmes initiaux avec la pipeline gitlab, affichant ainsi les mots de passes, ip et environnements de notre machine de test, la pipeline a été sécurisé par la suite grâce aux variables d'environnement gitlab, des clés ssh pour la connexion (comme dit plus haut) et toutes les informations ont été changées !
 
 ## Conclusion
 
@@ -181,7 +189,7 @@ Toujours faire des merge request
 
 1. **Liens vers les ressources :**
 
-- repo git : 
+- repo git :
 
 2. **Contacts :**
    - Fournissez les informations de contact des membres de l'équipe.