Messages

Notez tout de même que le CI de Gitlab permet de faire pas mal de truc intéressant. Compiler le client/serveur est une chose, mais il peut également :

-> Déployer automatiquement (ou manuellement) des environnement de test (des container docker par exemple)
-> Rollback les environnements quand ça passe pas

Exemple :

-> Quelqu'un commit sur Develop
-> Le CI lance le build du client et du serveur
-> Le CI déploie le nouveau build du serveur sur Spofu
-> Le CI met le nouveau client à disposition sur le FTP (dans le bon dossier)

Il est même possible de dynamiquement ajouter des enregistrement au serveur DNS, pour avoir par exemple une nouvelle adresse genre <commit>.spofu.khaganat.net, et un client pré-configuré pour s'y connecter.

Bien sur, les autres CI peuvent en faire de même, mais ils ne seront pas plus à l'abri de possibles bugs que Gitlab. en revanche, on perdra l'intégration du CI avec Gitlab, et l'expérience acquise sur ce CI.

Du coups, il semblerait que ce soit pour la Dimanche 2 Octobre à 21h.

A dimanche donc .

Je pense qu'il serait bon d'organiser une petite réunion, pour faire le point et présenter ce que l'on a fait depuis la dernière réunion.

Pour ma part, j'ai les sujets suivants à aborder:

1. Améliorations

• Rancher et ses possibilités.
  
  
  
  • Orchestration de container docker, sur de multiples hôtes
  • Configuration automatique de services utiles (reverse-proxy, health-check, etc.)

2. Organisation

• Utilisation de Gitlab
  
  
  
  • Gitflow
  • Les dépôts et les branches
• Les serveurs et leurs utilisation
  
  
  
  • Accès aux serveur
  • Le problème des ports des VM

3. Le futur de Khanat

• Rétrospective de la 0.2.0 (qui est plus ou moins terminée)
• Ce que l'on prévois de faire pour la 0.3.0

Sondage de présence: https://framadate.org/6YI5xhCChYF6Mc5h

Edit : sondage corrigé.

- Les gestionnaire de paquets ne peuvent pas mettre de fichiers dans les dossier utilisateurs (à ce que je sache tout du moins), ce qui exclut d'utiliser /home/[votre nom]

Pourtant il y a pleins de fichiers de config dans /home/user. Mais c'est parce que c'est généré par le logiciel lui-même au premier lancement et pas mis directement par le gestionnaire de paquets ?

Exactement

Pour que le patcheur mette les datas dans $HOME/.khanat, l'idée serait peut-être que le gestionnaire de paquet installe dans le dossier où il a le droit (/etc, /usr/share ?), mais qu'au premier lancement il créé dans  $HOME/ le dossier .khanat avec la copie du client_config, donc toutes les datas seront là. En gros, le client linux installe ce qui sert à lancer le jeu, mais stocke toute la configuration dans $HOME/ comme n'importe quel autre logiciel ; sauf que là, cette "configuration" c'est aussi les datas

Oui, c'est par exemple ce que fait GOG et Steam. Le gestionnaire de paquet installe un "installeur", qui s'occupe de DL et mêtre à jour Steam et tout ce qui est nécessaire avec.

Pour Linux, mon problème est le suivant :

- Le patcheur cherche les datas dans un dossier relatif au fichier "client_config" de base (celui qui est dans /etc/khanat), c'est à dire dans /etc/khanat/data.
- Le jeu, lui, le cherche dans /usr/share/khanat
- Les gestionnaire de paquets ne peuvent pas mettre de fichiers dans les dossier utilisateurs (à ce que je sache tout du moins), ce qui exclut d'utiliser /home/[votre nom]

Il faudrait recoder le patcheur pour qu'il puisse mettre les datas dans $HOME/.khanat (notez de $HOME, qui est automatiquement remplacé par /home/[votre nom de compte], équivalent à %USERDIR% dans Windows), chose que je ne sait pas faire.

Pour ma part, je serait tenté par le bi-xeon. Même s'il ne sont pas aussi puissants que l'i7-920 (pourtant vieux de presque 8 ans), il a plus de threads, ce qui veut dire que plus de process pourront être actif en même temps. Vu que l'on veut tout rassembler nos service sur ce serveur, ce serait très intéressant.

De plus, j'en profite pour suggérer de faire passer une partie de nos services sur des containers Docker, pour augmenter sécurité et souplesse, tout en profitant d'un environnement serveur reproductible à souhait. (placement de produit  )

Sur le point de la numérotation des versions, je serais plus pour garder la même numérotation que le client en lui-même (1.0.13 client = 1.0.13 data). Ainsi, l'utilisateur pourra plus facilement retrouver les datas correspondant à une version donnée du client.