Retour d'expérience #2 - Environnement de développement

Bonjour,

Aujourd’hui, je continue ma série sur mon retour d’expérience.
Pour ceux qui souhaiterais lire le précédent topic, il est disponible à l’adresse suivant :
https://community.gladysassistant.com/t/retour-d-experience-1/5759

Le sujet que je souhaiterais aborder ici est : la mise en place d’un environnent de développement pour contribuer au projet Gladys.

Disclaimer 1 : Je tiens à rappeler que les informations qui suivent sont subjectives. Il s’agit de mon expérience et des connaissance que j’ai accumulé. Je tiens a être cependant le plus constructif possible et reste ouvert à toutes critiques pour pouvoir m’améliorer.

Disclaimer 2 : Pendant les manipulations, aucun appareils électronique n’a été victime de maltraitance physique. Mais plutôt de la maltraitance verbale. Je me retiendrais donc d’utiliser ce texte comme exutoire à ma colère :wink:

J’ai découpé mes explications en trois parties :

  1. La première partie s’attardera sur la tentative d’installation de Gladys en mode manuelle (je n’ai pas utilisé l’image docker officiel). Je passerai les détails techniques et je me focaliserai plutôt sur les éléments que j’aurais aimé connaître ou essentiel avant de me lancer dans la préparation de l’environnement de développement.
  2. La seconde partie sera consacrée à une introduction à ce que pour moi un environnement de développement doit ressembler.
  3. Pour cette dernière partie, je souhaiterais vous expliquer mon début d’environnement de développement qui répond aux souhaits de la partie précédente, les premiers outils et l’architecture utilisée.

1. Installation manuelle

Dans cette partie, je vais essayer de ne pas trop m’attarder sur tout les détails techniques et les nombreux problèmes que j’ai rencontré.

Après avoir pris en main la partie configuration de Gladys et testé les premières fonctionnalités. J’ai consacré du temps à décortiquer le fonctionnement (dans les grandes lignes) de Gladys et de son environnement (systèmes, dépendances logiciels, architecture et fonctionnement interne).

J’ai ensuite voulu suivre la documentation disponible à cette page :

J’ai donc travaillé dans une machine virtuelle (VirtualBox) sur un ordinateur Windows 10. J’ai installé Debian Buster et commencé à suivre les instructions sommaires de la documentation. C’est à partir d’ici que les problèmes ont commencés.

Le premier point remonté est au sujet des “dépendances système” indiqué dans la documentation. J’ai choisi Debian Buster, mais j’aurais pu prendre une autre distribution où même Windows (mauvaise fois, vous allez me dire).
Ce que j’aurais aimé avoir comme indication, c’est quel est le système “recommandé” ou que la majorité des développeurs utilisent. Il est préférable d’utiliser une machine virtuelle ? Ou directement sur ça machine ? D’utiliser Docker ? C’est quoi docker ?
Je pense d’abord au nouveau venu. Ici il y a trop de possibilités et un nouveau venu qui souhaite faire partie de l’aventure pourrais se perdre en ne sachant pas par quoi commencer.
Il faudrait donc définir un ensemble de possibilités pour qu’un futur contributeur sache par quoi commencer. C’est-à-dire le guider sans le contraindre (mais plutôt avec une recommandation sur tel choix ou tel choix).

Après avoir installé toutes les dépendances sur la machine virtuelle, j’ai continué à suivre la documentation. Pour faire court, j’ai eu des problèmes de dépendances NPM non trouvées. Et que je ne pouvais pas lancer le serveur ou construire le front. À chaque fois que j’installais une dépendance manquante, une autre apparaît et ainsi de suite, une vraie galère. J’ai dû recommencer plusieurs fois de VM avant d’arriver à un résultat (merci la fonction de clonage pour simplifier l’installation d’une machine vierge).

Je me suis donc tourné par la suite sur Docker et ai construit une image docker pour pouvoir reproduire l’installation depuis une image d’un os vierge (Debian) et par lequel j’ai pu interagir pour effectuer mes différents tests d’installation des dépendances.
Le but ici a été d’automatiser et accélérer la production d’un environnement de type bac à sable. Ainsi, en lançant un container avec l’image construite j’ai pu tenter de reproduire les installations, les tests et l’exécution du serveur et du front (avec grandes difficultés).

Ce que j’aurais aimé savoir (et qui m’a pris du temps) c’est les différents mécanisme, processus et action possible.
Par exemple :

  1. Que l’on peut démarrer Gladys dans deux modes différents. Que pour le mode développement, on travaille avec deux serveurs différents.
  2. Qu’en mode développement, le front se construit à chaque lancée du serveur.
  3. Les options possible et modifiable ? Changer de port d’écoute des serveurs ou pas ?
  4. Qu’il existe différents tests réalisables.
  5. Qu’en mode production, il fallait construire d’abord le front, ensuite déplacer le dossier de build dans les statics du serveur et lancer le serveur en mode production.

En soit une documentation plus fournie sur les différents fonctionnements. J’ai dû trop chercher dans le code source pour comprendre certains points et c’était assez laborieux. Notamment dans CircleCI, où je suppose que peu de personnes savent ce que c’est et pourquoi c’est là (mais c’est un autre sujet que j’aimerai bien discuter, car intéressant).

Bilan

Pour conclure cette partie, l’élément important à retenir est qu’une documentation détaillée est très importante. Que ce soit pour la compréhension des différents mécanismes d’installation/build/test ou pour connaître les actions que l’on peut réaliser sur le projet. Car c’est bien pour du développement que l’on est là. :slight_smile:

2. Intro environnement de développement

Pour moi, c’est quoi un environnement de développement ?

Un environnement de développement est un cadre de travail dans lequel il existe un ou plusieurs outils permettant de réaliser les tâches de développement (écriture de code), de tests et de debuggage. Cet environnement devrait pouvoir ressembler à une salle de jeu où il est possible d’effectuer toutes les actions que l’on souhaite sans craindre des répercussions en dehors de ce cadre.

De plus, cet environnement devrait avoir un ensemble de principes.

  1. L’environnement de travail ne devrait pas perturber d’autre environnement adjacent. Il devrait être facilement déployable et pouvoir être nettoyé/supprimé sans incidence sur les environnements existants (par exemple le développement d’un autre projet).
  2. Chaque action doit être reproductible et fournir le même résultat. Cela permet une plus grande cohérence dans le processus de développement (cf. reproductibilité des erreurs).
  3. Malgré toutes les actions effectuées dans cet environnement, il devrait être simple et facile de pouvoir revenir dans un état propre et rangé. Si je continue ma métaphore de la salle de jeu, il devrait exister un bouton RAZ pour ranger la salle de jeu. Et ainsi recommencer à jouer dans de bonnes conditions.

Voilà ce que, personnellement, j’attends d’un environnement de développement.

Maintenant, je pense qu’il peut être bien pensant de définir et fournir un cadre de travail pour cet environnement de développement. C’est-à-dire fournir plus d’éléments dans la documentation associée. Ainsi, cela peut aider de nouvelles personnes, souhaitant s’investir dans le projet. Mais aussi, de permettre aux contributeurs de se concentrer sur le métier (c.-à-d. penser les fonctionnalités de Gladys et de les réaliser) au lieu de réfléchir et/ou débugger sur le système sur lequel ils travaillent.

Cela évitera de perdre potentiellement de nouveaux contributeurs lors de l’étape de mise en place (problèmes au niveau de l’installation de la machine virtuelle, de docker, de certaines dépendances NPM, etc.)

3. Mon environnement de développement


Le schéma de la figure précédente synthétise l’environnement que j’ai déployé pour pouvoir modifier, tester et exécuter le code source du projet.

J’ai déployé une machine virtuelle (sous VirtualBox) dans lequel le service Docker permet d’exécuter un ou plusieurs environnements système où le code source de Gladys est exécuté.
Les containers se basent sur une image Docker où je rassemble toutes les dépendances système ainsi qu’une première installation des dépendances des projets NPM (côté serveur et côté front).

J’ai rajouté une redirection de port dans la machine virtuelle pour pouvoir communiquer avec le container à l’aide d’un navigateur. Ainsi, je peux voir le rendu visuel et effectuer des tests depuis l’interface web.

J’ai intégré dans cet environnement l’IDE Virtual Studio Code recommandé par @pierre-gilles avec l’extension “remote-SSH”, je peux avoir directement accès à la machine virtuelle et ainsi modifier le code source du projet sur lequel je travaille. Ce même dossier qui est partagé avec les différents containers. Ainsi, à chaque lancement d’un container, les modifications sont prises en compte (synchronisation avec le dossier partagé).

J’utilise le terminal de VSCode relié à la machine virtuelle pour pouvoir builder l’image Docker de développement, ainsi que pour interagir directement avec le container (mode interactif, option “-it”, lors d’un lancement d’un container, commande “docker run”).

Exemple fonctionnement quotidien

  • Je lance VSCode et la machine virtuelle de développement
  • VSCode : Je me connecte au projet git disponible dans la machine virtuelle
  • VSCode : Je modifie un ou plusieurs fichiers du projet dans VSCode
  • VSCode : Je lance un terminal distant et lance un container basé sur mon image de développement
  • VSCode : (terminal dans le container) Je lance les tests à l’aide de NPM
  • VSCode : Je corrige une erreur de lancement
  • VSCode : Je quitte et relance un nouveau container pour prendre en compte les modifications et je test avec NPM
  • Browser : Je regarde/test le rendu
  • VSCode : je quitte le container (le container est détruit)
  • VSCode : Je valide mes changements en effectuant un commit sur le dépôt git.

Avantages de cet environnement

Le principal avantage de cette solution est de pouvoir être généré et distribué simplement. Partager une machine virtuelle et partager une image docker est simple. Ainsi, il suffit de configurer l’IDE à la machine virtuelle est le tour est joué.

Ensuite, la principale préoccupation pour moi est de ne pas vouloir installer des logiciels/dépendances spécifiques à un projet directement sur mon ordinateur. Avec cette architecture je n’alourdis pas mon ordinateur. Et pour nettoyer l’environnement, je supprimer uniquement la machine virtuelle.

Questionnement et évolution

Pour le moment je n’ai pas partagé le “Dockerfile” pour builder cette image de développement. Il reste quelques détails à valider. Je pense créer un autre sujet pour en discuter, si vous le souhaitez.

L’image docker a été tester uniquement avec les services dits “natifs” au projet, c’est à dire ceux disponibles dans les dossiers “services” des dossiers “server” et “front” du projet Gladys. Je ne sais pas à l’avenir comment se déroulera l’ajout de services, mais je pense que si chaque service est dans des dépôts git différent, il faudra adapté le mécanisme.

Fin

Voilà ! Ici s’achèvent mes explications.

Même si j’ai encore tant à dire, j’ai tenté de synthétiser mes propos et d’y apporter une proposition.

Je reste avec votre écoute pour toute question/précisions sur certains points que je n’ai pas approfondis ou mal expliqués.

Lanxor.

Je ne suis pas développeur mais je trouve ça très intéressant de mon point de vue.
Je pense que la force pour développer un projet open source viable sur le long terme comme Gladys est justement d’avoir des contributeurs/codeurs avec différentes techniques de travail et qui plus est, en font profiter la communauté.

Je ne peux pas dire si c’est bien, nul ou excellent ta façon de travailler, mais en te lisant je suis sûre que tu maîtrise très bien le sujet.

Hâte de voir tes contributions à Gladys.

1 Like

Intéressant comme environnement de dév !
J’ai installé simplement un environnement en suivant la doc sur macos et je trouve ça plus simple pour mon utilité. Par contre j’ai rencontré un soucis quand j’ai voulu utiliser un raspberry de test pour tester mon module, j’ai des soucis avec le front qui crash à cause d’un manque de mémoire pour le moteur JS… c’est possible de ne pas recompiler le front à chaque fois que l’on fait npm start ?

Je te relis demain à tête reposée mais ma première impression est “quelle usine à gaz”.

Il y’a cependant du boulot sur la doc.

Je m’excuse ! J’ai oublier de mettre mon schéma.
Je viens d’éditer mon post ^^

En soit, ce n’est pas forcément une “usine à gaz”. J’ai choisi de déployer mon image docker dans une machine virtuelle pour faire des tests et installer des composants dans un environnement propre. La partie “machine virtuelle” est donc un composant abstrait. J’aurais très bien pu vouloir lancer un container sur une machine distante (type rasbperry).

Le principal objectif de l’utilisation d’un container est de ne pas utiliser un environnement qui aurait été pollué. Ainsi, on se rapproche de l’environnement dit de production. Et à chaque modification, on est certain que les modifications qui fonctionnent, fonctionnent bien et ne sont pas le résultat d’une pure coïncident dues à l’environnement du système dans lequel on le teste.

Merci pour ton retour @Lanxor !

Je suis d’accord avec @VonOx, ça me parait un peu lourd comme process de dev, après il en faut pour tous les goûts si tu es confortable avec ce setup tant mieux :slight_smile: Le point qui va te ralentir c’est la lourdeur du process, si entre chaque modification tu dois stopper/relancer un container ça fait beaucoup. Pour comparer, en local sur ma machine si je fais une modification sur un fichier (back ou front), ça hot reload et en 500ms j’ai le changement live.

Effectivement le tutoriel “mettre en place un environnement de développement” sur le site c’est moi qui l’ai écrit, et comme je travaille sur un système unix (MacOS), c’est aussi simple que sur le tutoriel, un git clone, un npm install et un npm start et hop tout roule.

Je ne connais pas du tout Windows mais il est possible de faire plus simple en utilisant WSL. Je pense qu’on gagnerait beaucoup à avoir un tutoriel setup d’un environnement de dev Windows/WSL sur la documentation :slight_smile:

Je viens de relire ton super retour et je confirme mon ressenti ( c’est overkill ! :slight_smile: )

Je suis entièrement d’accord avec toi la doc doit être étoffé et complète pour un nouveau dev qui souhaitent contribuer.

Mais ! :smiley: Il y’a des limites à ce que l’on devrai documenter. Je penses que ce n’est pas à nous d’expliquer ce qu’est docker / github ou encore nodejs, ou plutot comment les utiliser. Chacun dispose déjà de sa propre documentation et on va pas réinventer la roue ( on peut rediriger vers leur doc ).


J’ai quelques commentaires

Je crois que la plupart de tes questions trouvent réponse dans le manifest


Je ne suis pas d’accord tout simplement car personne ne sera d’accord :stuck_out_tongue:

Exemple de débat sans fin!

  • Linux ok mais quelle distrib ? “moi je préfère debian” mais mon voisin préfère redhat etc…
  • “Moi j’utilise pas Windows c’est pas fait pour développer” etc…

On a la chance d’avoir un IDE/Une application cross platform, expliquons juste comment être pret à dev sur chacune des plateformes.

Comme tu le dit c’est un choix personnel.

Je me vois mal inciter les devs à créer une VM etc juste pour ne pas installer sqlite3 sur la machine ( oui je résume très simplement / la réalité et légèrement plus compliqué )

Le dev qui a tes besoins au niveau isolation a pour moi les compétences nécessaire pour se débrouiller.

PS:

  1. Tu les fais avec quoi tes schémas ?
  2. Je vais mettre à jour la documentation liée (Windows/Linux debian based) à la préparation de l’environnement de dev, j’aimerai te solliciter pour “valider” “tester” si tu es d’accord.

En effet je comprend vos appréhensions face à cette architecture.

Le principe fondamental de Docker est bien de pouvoir lancer à la volée et rapidement un nouvel environnement propre. Ce qui fait que à chaque modification, je quitte le container précédent (il se détruit automatiquement) et le lancement d’un nouveau container se fait en 1 seconde avec prise en compte des modifications effectuées.
J’utilisais Docker avec Jenkins pour pouvoir effectuer de la validation de code. J’ai simplement repris le même principe, mais au niveau du développeur.

Après, j’ai utilisé Windows car plus conviviale pour d’autres personnes. Mais le même schéma peut être reproduit sur une machine Unix sans difficulté. C’est uniquement une image docker à construire une première fois.

Ah ! ça aurait sympas d’avoir lu ce document avant, effectivement lol ^^ Je n’ai pas trouvé de référence pour le trouver sur le site, c’est normal ? ou c’est moi qui ne sais pas chercher ?

La machine virtuelle dans mon schéma est uniquement là pour avoir un environnement temporaire (comme quand on fait du pentest ou un Prouf Of Concept). C’est uniquement dans le container que l’on exécute l’environnement. Donc l’hôte modifie le code source, le container exécute et test le code source.

C’est vrai que j’ai une plus grande expérience au niveau des systèmes informatiques. Mais, ce que j’ai voulu partager, surtout, c’est de montrer qu’il était possible de créer un système accessible et facilement partageable (container).
Je pense qu’avec mes axplications j’ai perdu du monde :sweat_smile:

Je le fais avec Draw.io sur mon instance Nextcloud. C’est tellement fun. Et au boulot, mes collègues aiment bien mes schémas ^^

Demande, je verrais ce que je peux faire.

Voila la simplification du processus pour une machine Unix. Le but étant de ne pas exécuter le projet sur la machine locale.

Non ce n’est pas toi tu ne pouvais pas savoir :wink:

1 Like