Bonjour Bertrand,
J'espère que ça va ?
J'avais mis en place https://github.com/MedShake/MedShakeEHR ... ls/vagrant pour justement mettre en ligne et détruire à la volée des machines virtuelles de tests. Normalement le paramètre stage:"testing" synchronise les sources (si ce n'est pas le cas, il faudra me le dire que je le corrige). Normalement nos forks, s'ils sont à jour doivent disposer de ce dossier. Vagrant est dans les dépôts d'Ubuntu et dérivées, pour Debian il faut rajouter le dépôt, même principe il me semble pour virtualbox. Un vagrant up ça lance et installe Medshakeehr avec Ansible (avec la fibre et un ssd, il n'y a même pas le temps de se faire un café sinon c'est le moment d'y penser), un vagrant ssh pour accéder au shell, un vagrant halt pour arrêter, un vagrant destroy pour détruire la machine (il y a aussi un plugin pour synchroniser le fichier host du pc hôte que je n'ai pas encore testé pour automatiser encore plus). Vagrant snapshot aussi, si envie de faire les choses bien et de ne pas enchaîner les vagrant up et destroy (je plaide coupable)
Au passage ça pourrait aussi être une méthode pour automatiser la sortie d'une machine virtuelle de démonstration à chaque nouvelle version, mais je n'ai pas encore compris comment installer les modules en cli et comment faire fonctionner villagepeople, ça fait partie de mes projets
Deuxième astuce docker. L'avantage et qu'on peut se créer un volume qui se synchronise directement avec le container (c'est comme ça que j'ai pu tester finalement php8, en me logguant sur un container php7 pour avoir le saint cookie et en relançant en php8). Quand je tente des bidouilles sur les templates, controller et autres, c'est ce que j'utilise. Je modifie sur mon ide je recharge la page et je regarde ce que ça donne. Inconvénient il y a des bugs propres à la conteneurisation. Exemple typique sur LXC ou Docker, la page des taches crons "n'enregistre" pas les cases cocher et ce n'est pas que visuel. Je me suis retourné le cerveau à essayer de comprendre d'où ça pouvait venir (dans les containers lxc à priori il y a le lamp en entier par exemple donc ce n'est pas une question d'isolement déjà). Donc tout n'est visiblement pas testable. Autre problème je n'ai jamais réussi à faire fonctionner les versions de Indelog et de bugeaud, j'ai donc fait ma propre version qui n'est pas à proprement parlé une dockerisation (c'est en cours de réflexion) de medshakehr mais qui est une dockerisation du serveur lamp de medhsakehr. Il a l'avantage de régler les problèmes rencontrés par Indelog et bugeaud sur le sha de composer, en dockeurisant composer, et gère le ssl et allége un peu le conteneur php de medshakeehr (de 200 ou 400 mo je ne sais plus, ça reste un beau bébé de 800mo), mais présente encore des bugs. Notamment lors de la validation de la base de données, il faut rafraichir pour enlever un message d'erreur d'où le fait que je ne vous l'avais pas encore partagé.
Pour les plus curieux et prêt à subir des trucs bizarres c'est par ici [https://github.com/marsante/MedShakeEHR ... ompose.yml
Après moi je ne suis pas développeur, jusqu'à présent j'ai surtout corrigé des petits trucs qui ne nécessite pas des tests de fou et monter et détruire une VM est suffisant, peut être que Indelog à des méthodes plus propres, parce que moi j'ai une longue liste de cadavre de vm derrière moi j'ai entendu parlé de test unitaire quelque part, mais vu le niveau que j'ai pu démontrer en php jusqu'à présent, ce n'est pas moi qui vais pouvoir aider
Dernier point j'avais vu une équipe de développeur sur github, se répartir le travail avec ceux peu technique qui géraient les réponses des issues ou les étiquetaient pour les plus techniques, de même pour les pullrequest et les développeurs techniques qui reviewaient le code. Je pensais que github permettait de donner des rôles fins à chaque utilisateur et que ça pouvait être cool de s'organiser comme ça. Sauf que de ce que j'ai pu comprendre de la doc c'est du tout ou rien et ça peut vite amener à des conneries.