Je commence à m'intéresser à l'intégration continue, même si je suis en retard d'une guerre. Et je me rend compte en réfléchissant rapidement, qu'on s'est engagé sur la voie de gitlab-ci sans vrai réflexion et analyse en amont. Ce n'est peut-être pas le meilleur choix. Il est possible d'avoir un CI découplé de gitlab, je vous propose d'analyser ça sauf si vous avez déjà des habitudes fermes avec gitlab-ci.
L'intégration continue fait partie de l'automatisation du Système d'Information et du développement applicatif. Je suis pas pour une réflexion sur le Gitlab-CI mais sur une étude global du projet Khaganat.
Je m'explique, pour mettre un pied dans l'automatisation, nous devons avoir une vue d'ensemble de l'architecture. Automatiser le développement nécessite des outils sur l'infra, infra qui est le socle du développement et de la production.
Ne devrions nous pas commencer par faire une étude général que nous découperions par priorité ?
- Quels sont les besoins et pourquoi ?
- Quels sont les problème récurrent rencontrer ?
- ...
- Peut on répondre a tous les besoins avec l'existant ?
- Que peut on ou non automatiser et pourquoi ?
- ...
Il y a certainement d'autres questions a poser auquel je ne pense pas.
De plus, si cela a déjà était fait je m'en excuse mais je n'ai rien trouver sur le Wiki.
<SIELA1915> besoins: compiler les clients automatiquement, et les packager comme prévu (smokey, full etc) ainsi que compiler tous les outils et une vm avec le serveur
Les besoins en terme d'automatisation et de CI sont surtout liés à la compilation des clients et des serveurs.
Le reste de l'infra est stable. De mon point de vue, ce n'est pas la peine d'automatiser la création de VM car c'est une tâche rare, et chaque fois le besoin sera différent. Les bénéfices d'un automatisation seront faibles en rapport au travail à fournir pour y arriver de façon satisfaisante.
On a donc un serveur de gestion de versions, gitlab, avec deux fonctions distinctes :
- Créer les clients de jeu
- Suivre les évolutions des serveurs.
Pour les serveurs, ils sont deux : lirri et spofu. Spofu reçoit les nouveautés, lorsqu'elle sont validées elles sont basculées vers lirria. Les développeurs peuvent avoir un serveur de jeu personnel qui leur permet de faire les premiers tests avant de push sur spofu. Tout ça devrait être intégré.
Pour les clients, c'était assez au point il me semble, je laisse siela détailler
En ce qui concerne l'infra, je suis d'accord que l'on n'en crée pas souvent de VM, c'est un fait.
Toutefois il est possible de facilité la création de ses dernière sans surcharge de travaille pour la suite.
le fichier /etc/xen-tools/xen-tools.conf permet notamment de mettre en place des choix par défaut tel que :
- le groupe de volume ou sera crée les VM
- Les paramètres réseaux gateway, netmask, broadcast et le serveur de nom(DNS)
- L'utilisation de pygrub
- L'exécution automatique des VM après création
Le but est d'automatiser si besoin mais surtout facilite les choses si elles ne peuvent ou n'ont pas lieu être automatiser.
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.