GitLab now enforces expiry dates on tokens that originally had no set expiration date. Those tokens were given an expiration date of one year later. Please review your personal access tokens, project access tokens, and group access tokens to ensure you are aware of upcoming expirations. Administrators of GitLab can find more information on how to identify and mitigate interruption in our documentation.
L'objectif du projet est de créer une application web et mobile communiquant avec une API et de la déployer. Sur cette application, il est possible de jouer, créer des quiz (manuellement ou avec IA), seul ou à plusieurs, avec un timer ou non.
## Pipeline d'intégration continue
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.
### 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.
sudo docker compose up -d --remove-orphans --build permet de force le build des dockers si jamais les images ont changés, remove orphan de supprimer les service inutilisés (suite à de smises à jour)
## Gestion du dépôt Git
1.**Messages de commit :**
Au début du projet, nos commits se devaient d'être atomique et avaient un nombre limité de mots dans le message (15 par convention)
Après les cours d'A52, nous avons fait sauter cette seconde convention.
2.**Processus de revue de code :**
Malgré le manque de délai, nous avons essayé de review le code de l'application web à deux, entre les 3 personnes les plus concerné sur ce côte de l'application : Maxime, Samuel et Jawad.
On commençait par une démo de la feature ou correction. Pour repérer les élements les moins ergnomique ou étranges. Puis nous regardions le code ajouté, en discutant du "pourquoi telle méthode", "pourquoi pas une autre".
Mais la plupart du temps, nous ne pouvions (par manque de temps) qu'essayer l'application via le front mobile ou web et, si cela fonctionnait, merge request et continuer de coder.
3.**Workflow :**
Voici le workflow, dispo sur notre confluence ( <https://glazk.atlassian.net/wiki/spaces/DL/pages/4882435/Workflow> )
```markdown
### Pour démarrer une nouvelle tâche
- Sur Gitlab, regardez les tâches (issue)
- En choisir une et vous l'assigner
- _Eventuellement, créez vous-même des sous-tâche dans votre issue actuelle pour montrer votre avancée à vos coéquipiers et/ou vous aider à réfléchir_
- Appuyez sur la flèche bleu à côté de `create merge request` et choisissez `create-branch`
- Changez le nom de la branche pour suivre les conventions (exemple feature-xxx)
- Sélectionner `develop` en tant que source
- En local, faites un `git fetch origin --all --prune` pour récuperer notamment votre branche (**attention --prune supprime les branches qui ont été complètement mergées/supprimées sur origin**)
- Faite un `git switch feature-xxx`
- Bossez et commitez dessus
### Une fois la tâche terminée
- Sur votre pc, git push origin feature-xxx
- Sur Gitlab, appuyez sur 'compare' puis 'créer merge request' OU directement sur 'créer merge request' s'il est proposé
- Assignez qqun en reviewer (Jawad, Samuel et/ou Nicolas en priorité, vos autres collègues sinon)
- Cochez les options `delete source` et `squash`
- Confirmez, la merge requets est maintenant créée
- Choisissez une nouvelle tâche (\> voir section d'au-dessus)
_Votre tâche sera validée ou non par votre reviewer, qui mettra en commentaires ce qui ne va pas si besoin_
### Branches
- master
- develop
- accueille les features et les fix terminées
- à chaque merge dessus, la CI/CD lint, build, test toute la solution.
- une fois une version livrable atteinte (v0, v1, ...), merge squash vers releases et le commit est taggé
- features-xxx et fix-xxx
- accueille les tâches en cours, isolées les unes des autres
- à chaque push dessus, la CI/CD lint la solution.
- une fois terminée, merge squash vers develop
- releases
- à chaque merge dessus, la CI/CD lint, build, test toute la solution.
```
4.**Documentation :**
Nous avions une documentation très détaillé en début de projet, surtout pour l'api, disponible sur notre Confluence <https://glazk.atlassian.net/wiki/spaces/DL/pages/4456450/API> avec les routes, les types DTO, etc. Chaque ligne de code (à peu de chose près) avait le droit à son petit commentaire.
Néanmoins, il était non seulement très long de mettre à jour et nous faisais perrdre du temps mais aussi trop pénible à lire.
Nous avons donc réduit la documentation au strict minium : un swagger (qui génère et affiche la documentation avec peu d'ajout de code) et des commentaires de code seulement là où nécessaire (code difficle à comprendre ou à ne pas modifier).
Au départ sur gitlab wiki, nous les avons déplacer sur Confluence en même temps que nos issues sur Jira (même environnement) pour un devoir de Management. Avec la réduction des besoins de documentation (raisons exprimé plus haut et fait qu'on retiens les convention à force), nous avons laissé sur confluence. Cependant, nous sommes revenus sur Gitlab issue afin de profiter des nombres automatisation : créer une branche et une merge request covnentionnée en un clic, pouvoir réferer des tâches, des soucis, des branches, des utilisateurs à n'importe quel endroit pour éviter d'avoir à naviguer pendant des heures pour trouver ce qu'on cherche.
5.**Conventions de programmation :**
Voici l'extrait de notre Confluence <https://glazk.atlassian.net/wiki/spaces/DL/pages/4096003/Convention> :
