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.
@@ -67,7 +67,7 @@ docker-compose -f docker-compose.prod.yml up -d
## Ancien protocole d'installation
Au besoin, les rares anciennes documentations et info transmise par l'ancien groupe en charge du développement de Gyokerske sont disponibles ici.
Au besoin, les bribes de documentation et info transmises par l'ancien groupe en charge du développement de Gyokerske sont disponibles [ici](https://git.unistra.fr/jagermasters/gyokeres-deploy-assistance/-/blob/main/Ancien%20protocole.md?ref_type=heads). Nous y avons ajouter un guide de création d'apk pour distribuer l'application mobile.
## Problèmes repérés
...
...
@@ -88,3 +88,32 @@ Au besoin, les rares anciennes documentations et info transmise par l'ancien gro
- Dans la CI/CD les tests et le lint ne marche pas, dans le sens où il est mal configuré, il manque des dépendances
# Notes complémentaires
## Interactions inter-équipes
Deux groupes sont venus nous redemander un petit topo sur mon ancien projet, Kwizosn car la doc n'était pas à jour par manque de temps. Je leur ai fourni les instructions simplifié et à jour (non push pour rester dans la logique du rp) de comment j'avais réussi à déployer le projet.
Un groupe est revenu me voir, quelques temps plus tard, car les instructions étaient erronées... Sauf qu'en discutant plus longuement avec lui, j'ai bien vu que les membres
- n'ont soit pas lu les instructions, préférant RE-demander des choses déjà dites dans une doc pourtant concise (car l'ancienne doc était aussi trop longue selon eux)
- choisi une branche aléatoire pour déployer (pourquoi ?)
- revenait me voir pour me demander si telle ou telle feature était en place, pour que je leur indique que "oui, comme c'est visible dans l'interface" avant de voir qu'ils n'ont pas essayé de lancer...
- me demandaent pourquoi il n'y a pas de script pour lancer facilement l'application entière (ex un init.sh), alors que nous avons suivi la logique de docker compose qui le fait déjà à votre place en une seule commande simple, à la fois dispo sur notre doc, celle officielle (et ayant été vu en cours si on sort du rp).
En tant que membre ayant écrit plus 60% du projet "Kwizos by The Sevens", j'ai bien conscience que certaines fonctionnalité sont instables... Contrairement au déploiement, qui a fonctionné sur plusieurs machines différentes au fil du projet, de manière efficace puisque nous avons dû changer 3 fois d'hébergement de serveur (j'ai même dû le remanier plusieurs fois pour pouvoir le lancer sur ma propre petie Rasberry pi ).
Je suis juste surpris par les bruits de couloir, les groupes qui râlent sans demander d'indications pour autant, et m'inquiète du manque d'interaction avec les membres de _The sevens_ alors que TOUS _devraient être_ disponibles pour répondre aux questions, _pas seulement moi_.
Il faut donc avouer que, de mon point de vue, la situation est telle qu'une partie des groupes ayant reçu Kwizos partent du principe que "le projet n'a pas l'air bien à première vue, ils ont pas eu une bonne note, alors je ne fais rien et renverrai la faute sur les autres". Là où l'autre moitié tente des choses... extravanguantes (même si je ne saurais dire s'ils le font pour le roleplay ou non).
J'ai déjà subi la douloureuse note de ce projet lors du développpement, j'aurais tous fait pour aider les membres des autres groupes (sans pour autant leur faire 100% du travail). Donc je voulais mettre en garde ici, pour la correction, pour ne pas entrer dans un cercle vicieux non mérité.
Enfin, et cette fois pour être plus taquin, je précise que le groupe qui nous a le plus critiqué de face, en tout bine tout honneurn a lui aussi des problèmes avec leur ancien projet (aucune documenttion, script modifiant les configurations docker bloquant des projets pourtant indépendants, non respect de beaucoup de convention vues en cours et présente en entreprise, ....). Or là, les gens (nous et les autres groupes l'ayant reçu) essayent et réussissent à déployer !
-- Samuel
## Configuration du docker
Le script de lancement du groupe Gyokereske apporte une configuration spécifique à docker tout en "forçant" l'utilisateur à être sur une machine linux.
Autant la deuxième anomalie est réglable en précisant une image docker basée sur linux (exemple les versions "alpines" des images x ou y), autant la première a perturbé le projet d'alternance et provoqué plusieurs heures de debug sur un projet qui n'avait pourtant rien à voir...
Les groupes sont venus nous redemander un petit topo car la doc n'était pas à jour. Nous leur avons fourni un README simplifié et à jour (non push pour rester dans la logique du rp), et effectivement nous avons pu déployer de notre côté notre projet en suivant les instructions.
Une partie des groupes est revenu nous voir, quelques temps plus tard, car les instructions étaient erronées... Il s'avère que ces groupes :
- n'ont soit pas lu les instructions, préférant RE-demander des choses déjà dites dans une doc pourtant concise
- choisi une branche aléatoire au lieu du main ou même du develop pour déployer (pourquoi ?)
- pas essayé de lancer... et revenait nous voir pour savoir si telle ou telle feature avait été mise en place...
Autrement dit, on voit ici le principe du "le projet n'a pas l'air bien à première vue", "alors je ne fais rien et renverrai la faute sur les autres". Sachant évidement que les mêmes problèmes sont rencontrés pour leur ancien projet, mais les gens essayent et réussissent.
## Configuration du docker
Le script de lancement du groupe Gyokereske apporte une configuration spécifique à docker tout en "forçant" l'utilisateur à être sur une machine linux.
Autant la deuxième anomalie est réglable en précisant une image docker basée sur linux (exemple les versions "alpines" des images x ou y), autant la première a perturbé le projet d'alternance et provoqué plusieurs heures de debug sur un projet qui n'avait pourtant rien à voir...